Multi-processing financial transaction processing system

ABSTRACT

A financial transaction processing system is disclosed, wherein substantial processing efficiencies are provided with, additionally, a substantial decrease in the size of the executable code. Each transaction processed by the transaction processing system is described by a transaction data descriptor that includes a series of subtransaction data descriptions of actions that can be performed independently of one another. Thus, complex transaction processing logic is substantially removed from the executable code, and instead such transaction data descriptors are processed interpretatively. Moreover, the independence of the subtransactions allows the subtransactions of a transaction to be processed in parallel when performed on a multiprocessor computer. Additionally, the transaction processing system provides account balancing enhancements in that there are control columns in various data tables that are automatically updated during transaction processing so that by comparing control column totals, an indication of the integrity of current financial records is provided. Additionally, the transaction processing system provides full auditability in that any changes to financial data can be traced for any effective period of time into the past so that auditors can periodically perform a full audit of the financial transaction data retained by the transaction processing system.

FIELD OF THE INVENTION

The present invention relates to a financial transaction processingsystem, and in particular, to such a system that is capable ofdecomposing transactions into subtransactions and multi-processingsubtransactions simultaneously.

BACKGROUND OF THE INVENTION

Computerized data processing systems for processing financialtransactions have become increasingly more complex as further stridestoward automation have occurred. Such complexity has generated a numberof related difficulties for the financial data processing industry. Inparticular, complex financial transaction processing systems may havesubtle programming defects or errors that may go unnoticed for longperiods of time before the extent of the problems thereby generated arefully recognized. For example, the number of positions allotted for thedating of transactions has recently been problematic, wherein the datesfor the millennium starting at the year 2000 can be problematic for manyfinancial transaction processing systems.

In addition, such complex financial transaction processing systems alsoare typically incapable of being fully audited. That is, it is commonpractice in the financial data processing industry to provide onlypartial auditability in that it is generally believed that the amount ofdata required to be stored for full auditability is so large as to notbe cost effective.

Further, in many circumstances, the rate of transaction increase isbecoming problematic in that progressively larger computers are requiredfor processing financial transactions at an acceptable rate. Thisproblem is exacerbated by the fact that such transaction processingsystems are not architected for use on multi-processing machines havinga plurality of processors. Thus, the advantages of parallel-processingcomputers cannot be fully utilized by such systems.

Accordingly, it would be advantageous to have a financial transactionprocessing system that alleviates the above difficulties, and thatadditionally, provides flexibility to adapt to the changing businessneeds of business enterprises so that the transactions processed and therespective reports generated may be modified easily according tobusiness constraints and demands.

SUMMARY OF THE INVENTION

The present invention is a financial transaction processing system thatachieves substantial increases in auditability and processingefficiency. In particular, the present invention provides auditabletrails or history in a number of different ways. For example, financialdata within transactions is used in the present invention to updatevarious control fields in different tables or files so that cross-checksof system financial integrity can be performed for assuring that, forexample, cash fields, total units fields, and cost fields balanceappropriately across system data tables provided by the presentinvention. Additionally, the present invention provides a full range ofauditable history files for each system data table having informationthat is required during auditing.

The present invention also performs financial transaction processingusing a novel computational paradigm. That is, the financial transactionprocessing system of the present invention has an architecture whereinfinancial transactions can be decomposed into corresponding collectionsof independent subtransactions, such that for each input transaction,the corresponding collection of subtransactions are performed byoperations that are independent of one another. Thus, thesubtransactions can be performed in any order, including in anoverlapping fashion, such as may occur during multiprocessing of thesesubtransactions on a computer having multiple processors.

Further, note that each of the subtransactions is described by arelatively short (e.g., less than 8 characters) text string that can bestraightforwardly interpreted as an operation (e.g., either plus orminus) together with a series of operands, in particular, a firstoperand having a value to be used in modifying a data table field(column) specified by a second operand. Such high level descriptions ofsubtransactions provide both compact conceptualization and a reductionin the total size of the executable code for the present invention.Accordingly, when one of the subtransactions is performed, not only isits corresponding operation performed on the operands, but additionally,control fields such as those mentioned above are updated appropriatelyin various data tables for the present invention to enhance auditabilityof the financial data resulting from the transaction processing.Further, note that since the subtransactions are independent of oneanother and their executable code is relatively small, there is no needfor lengthy and complex flow of control transaction processing modules.That is, the size of the code for the present invention may be up to 100times smaller than many prior art transaction processing systems.Accordingly, this has a substantial positive impact on the efficiency ofthe present invention in that the swapping of program elements in andout of primary computer memory is substantially reduced.

In another aspect of the present invention, the financial transactionsof a plurality of business enterprises can be processed in aninterleaved manner. In particular, since the present invention issubstantially data driven, including the descriptions of thetransactions and their related subtransactions, the present inventioncan be easily modified to incorporate both different or updated versionsof transactions and associated data tables for an existing businessenterprise (e.g., also denoted “licensee” hereinafter). Additionally,the transactions and related data tables for an entirely new ordifferent business enterprise (licensee) may be straightforwardlyincorporated into the present invention so that its transactions can beinterleaved with the transactions of other business enterprises. Thus,transaction processing may be performed by the present invention forbusiness enterprises having different transactions, different accountrecord structures and differently organized general ledgerssubstantially without modifying the program elements of the transactionprocessing system.

For example, the present invention can be used to simultaneously processtransactions for:

-   -   (1) a single software application such as an investment        management or telecommunications billing system,    -   (2) multiple disparate software applications such as investment        management, and telecommunications billing, paying agencies,        etc., all with disparate definitions.

Accordingly, the present invention may be viewed as a software engine,or a user-definable transaction processing tool that can be adapted to avariety of industry specific software application needs without changingthe actual program code. That is, by surrounding the present inventionwith application specific software for inputting transaction data to themulti-processing financial transaction processor of the presentinvention and retrieving data from the multi-processing financialtransaction processor of the present invention, a particular businessenterprise can have substantially all of its financial records incondition for auditing on a daily or weekly basis.

The present invention may be further characterized along the followingdimensions: flexibility, auditability, multiprocessing, efficiency andsize, these dimensions being discussed, in turn, hereinbelow.

Flexibility is achieved by permitting a business enterprise to define:

-   -   (1) a series of “reference” tables (also denoted “master        tables”) that describe the appropriate management        decision-making, accounting structure, and regulatory        information for the specific application;    -   (2) a series of audit controls and system procedures that        provide for complete control of all processing and prevent the        overwriting of any original data;    -   (3) a series of institutional and customer reporting files,        known as the “driven” tables; and    -   (4) the specific processing content of each individual        transaction to be processed via a series of table definitions,        known as the “driving” tables.        Thus, transactions may be customized according to the business        needs of a business enterprise.

Auditability is achieved by:

-   -   (1) providing separate control columns for cash, units and cost        basis (if any) in detail records generated and stored for each        financial transaction;    -   (2) repeating these three control columns, or variations        thereof, in at least three different tables so that subsequent        summations of each of the four tables will result in similar        balances and thus prove that no critical data has been lost in        the course of processing, as one familiar with auditing and        financial transactions systems will understand;    -   (3) adding appropriate data columns:        -   (a) to each reference table or master row for maintaining a            history of the effects of add, change and delete commands in            a current database as well as an archive database;        -   (b) to each original file record (i.e. table row) that            represents an add to a current database as well as the            periodic archive and purge to a permanent database;        -   (c) to tables for retaining transaction processing data            representing error identification, error negation and error            correction.            Thus, auditabilty of transaction records is achieved by four            sets of files for a specific period. These are: (a) a            snapshot of all the reference files at the end of the            period; (b) snapshots of a history file for each master            table, wherein the corresponding history file (table)            contains all changes to the master table during the specific            period; (c) a snapshot of all financial transactions for the            specific period, and (d) a snapshot of all of the “driven”            tables at the end of the period.

Multiprocessing is achieved by:

-   -   (1) decomposing the processing of the present invention into a        series of separate and independent subprocesses that may be        simultaneously performed on any number of simultaneous        processors, and    -   (2) decomposing input transactions into a series of        subtransactions that are processed by independent processes,        which may be executed in any particular order, with complete        auditability.        For example, multiprocessing can be achieved by allocating the        next prescribed subtransaction process to the next available        processor.

Efficiency is achieved by:

-   -   (1) Defining and utilizing only four standard processing models        that perform all prescribed functionality and auditability of        the present invention. The models are:        -   (a) Processing Model 1 provides an architecture for            maintaining historical transaction data so that financial            changes can be traced through time;        -   (b) Processing Model 2 provides an architecture for            automatically maintaining data columns such as Units, Debits            and Credits for cross checking table sums to assure that the            financial records for a business enterprise balance;        -   (c) Processing Model 3 provides an architecture for            automatically maintaining financial records relating to            financial instruments such as stocks, bonds, real estate,            etc.; and        -   (d) Processing Model 4 provides an architecture for            producing a common processing format for maintaining            customer and institutional data tables.    -   (2) Defining only four primary program modules for controlling        functionality of the present invention, these modules being:        -   (a) a transaction processing controller module for receiving            transactions to be processed, and controlling the processing            thereof;        -   (b) a preprocessor and decomposer module for determining the            validity of a received transaction, assuring that all data            tables and rows thereof are available for processing the            transaction, and retrieving the appropriate subtransactions            data descriptions to be processed;        -   (c) a subtransaction scheduling module for scheduling            instantiations of the subtransaction processing module on            each of one or more processors; and        -   (d) a subtransaction processing module for performing each            subtransaction retrieved by the preprocessor and decomposer            module.    -   (3) Utilizing a number of software switches to control which        tables within collection of “driven” tables are to be updated        when a specific type of transaction is to be processed.

Thus, by providing a small number of processing models, decomposinginput transactions, and supplying only the necessary subtransactiondescriptions, the reliability of the transaction processing system ofthe present invention is substantially increased.

The software for the present invention is small in size (both sourcecode and object code) due to the following:

-   -   (1) defining business enterprise financial data processing        methods, accounting structures, and regulatory definitions as        data rather than program code;    -   (2) reducing the processing content to a series of individual        transactions; and    -   (3) reducing all financial transactions to a collection of        subtransactions wherein each subtransaction includes an operator        and two or more operands in an 8-character string.        Thus, the financial processing by the present invention may be        performed on several transactions at a time, one transaction at        a time, or different processors within a multiprocessor context.        Or, the subtransactions for a specific transaction may be spread        over several simultaneous processors. This means that the        business enterprise is afforded a large number of options in        tailoring the present invention.

Hence, by defining the accounting structure and processing functionalityas data rather than actual program code, the size of the total coderequired to process a specific industry application may be substantiallyreduced compared to prior art transaction processing systems. Forexample, the executable code for the present invention may be less thanone megabyte (1MB). Thus, since the secondary cache attached to eachprocessor in multiprocessing personal computer servers can be onemegabyte, substantially the entire executable for the present inventioncan be provided to each processor. Thus, the positive impact on totalsystem efficiency is believed to be substantial in that secondary cacheis typically about four times faster than normal cache, so productivitygains of about three-hundred percent would not be unreasonable. In otherwords, the executable code for the present invention can reside in thesecondary cache of each processor, thereby allowing the off-loading ofany processing function to any processor with relative ease.Additionally, given that a typical RAM memory for a personal computingdevices is 16 megabytes, it is believed that such a device will have thecapability to process the back office financial transactions of a majormoney center financial institution or communications billing system.

Additional features and benefits of the invention will become evidentfrom the detailed description and the accompanying drawings containedherein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high level block diagram illustrating the present inventionconceptually.

FIGS. 2A and 2B is another block diagram of the present inventionillustrates: (a) the high level transaction processing modules, and (b)the data tables (represented by the symbols with arcuate vertical sides)provided and maintained by the present invention. Furthermore, thepresent figure shows the data flows as solid arrows and control flows asdashed arrows. Moreover, this figure also indicates the data tableseffected by process models No. 2 and No. 3 of the present invention.

FIG. 3 is another high level block diagram of the present inventionduring activation of the preprocessor and decomposer 54 wherein thesolid arrows are illustrative of the data flows that occur during theactivation of the preprocessor and decomposer 54. Moreover, the tableswithin boxes represent tables having a process model No. 1representation, and the tables having account balancing control fieldsinclude the identifier, “CNTLS.”

FIGS. 4-A through 4-E illustrate the steps of a flowchart forinitializing the database tables of the present invention for a newbusiness enterprise licensee that is to have its financial transactionssubsequently processed by the present invention.

FIG. 5 is a block diagram illustrating process model No. 1 of thepresent invention.

FIG. 6 is a high level flowchart of the steps of an embodiment of thetransaction processing controller 52 of FIG. 2A.

FIGS. 7-A through 7-D show the high level steps performed by anembodiment of the preprocessor and decomposer 54 of FIG. 2A.

FIGS. 8-A and 8-B show the steps of a flowchart for obtaining indexes orpointers to particular rows of a general ledger table wherein the rowsare used in processing a transaction.

FIGS. 9-A and 9-B show the steps for a flowchart of an embodiment of thesubtransaction processing module 64 (FIG. 2A).

FIG. 10 is an embodiment of a flowchart of the steps performed forprocessing income cash transactions by the present invention.

FIG. 11 is an embodiment of a flowchart of the steps performed forprocessing principal cash transactions by the present invention.

FIG. 12 is an embodiment of a flowchart of the steps performed forprocessing invested income transactions by the present invention.

FIG. 13 is an embodiment of a flowchart of the steps performed forprocessing invested principal transactions by the present invention.

FIG. 14 is an embodiment of a flowchart of the steps for performingcustom accounting such as income expenses, and cash flow for a businessenterprise.

FIG. 15 is an embodiment of a flowchart of the steps for maintaining abusiness enterprise's balance sheet related to buys and sells offinancial entities or instruments.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

FIG. 1 shows a high level conceptual block diagram of a transactionprocessing system 50 according to the present invention. In particular,the present invention is conceptualized in the present figure asincluding five functional components, these being:

(a) transaction processing controller 52 for: (i) receiving transactions58 from business enterprises, (ii) controlling the processing of suchtransactions, including the scheduling of subtransactions to beperformed, and (iii) writing of transaction details to, for example, atransaction journal file or table;

(b) a transaction preprocessor and decomposer 54 for initially receivinga transaction 58 from any one of a plurality of business enterprises asshown, wherein the preprocessor and decomposer 54 decomposestransactions into subtransactions;

(c) a subtransaction processing module 64 for performing theinstructions for each subtransaction determined by the transactionpreprocessor and decomposer 54. In particular, the subtransactionprocessing module 64 utilizes a collection of subtransactionprogrammatic data descriptions 66 that can be independently scheduledand performed for processing each transaction 58 provided to thetransaction processing system 50;

(d) a subtransaction scheduler 62 for scheduling the execution of eachsubtransaction output by the preprocessor and decomposer 54;

(e) a collection of databases 70 containing financial information foreach of the one or more business enterprises. Note that the term“database” in the present context includes both the data therein as wellas database management functional elements and data structuredefinitions.

Another illustration of the present invention is provided in FIG. 2.This figure is a block diagram providing both the processing componentsof FIG. 1, and additionally, greater detail is provided of the tables orfiles within the databases 70. However, to simplify the discussionhereinafter, the database terminology used will be that of a relationaldatabase. Accordingly, files may also be equivalently referred to astables, records may also equivalently be referred to as rows, and recordfields may also be equivalently referred to as columns. Thus, all thedata storage symbols having the collective label of 70 are providedwithin the like numbered databases of FIG. 1. It is worth noting,however, that in one embodiment of the present invention, the datatables for distinct business enterprises may be provided in the samecollection of tables such as those represented in FIG. 2. That is, it isan aspect of the present invention that the accounting and transactionprocessing of the present invention can use the same plurality offinancial data tables for business enterprises having substantiallydifferent financial transactions and accounting categories. Thus,although FIG. 1 illustrates the databases 70 as being distinct for eachbusiness enterprise, many of these databases (if not most) may becombined into a single database having a plurality of data tables suchas those labeled collectively “70” in FIG. 2, these tables beingdiscussed in detail hereinafter.

Referring still to FIG. 2, a high level view of the processing performedwhen processing a transaction 58 is provided. In particular, thetransaction processing controller 54 receives an input transaction 58and invokes the preprocessor and decomposer 54. The preprocessor anddecomposer 54 subsequently performs, for each transaction 58, thefollowing functions:

-   -   (a) determines, using input from the business enterprise        databases 70, whether all necessary data for performing the        transaction is available and otherwise rejects the transaction        without performing any portion thereof. In particular, the        transaction preprocessor and decomposer 54 determines that all        data tables to be accessed are available;    -   (b) retrieves the data needed to perform the transaction;    -   (c) checks to determine that the transaction operation(s)        requested is available, and that the transaction is legitimate        to be performed on the data for the input transaction 58;    -   (d) retrieves the subtransaction data descriptors for        decomposing the input transaction 58 into subtransactions.        Accordingly, the preprocessor and decomposer 54 retrieves into        the working storage 72 (shown in FIG. 3) of a host computer (not        shown), upon which the transaction processing system 50 is        operating, substantially all data and table rows that are        necessary to process the transaction 58. Additionally, note that        as one skilled in the art will understand, if some portion of        the required data to process the transaction is unavailable,        then the preprocessor and decomposer 54 terminates processing        and subsequently writes appropriate error messages and/or        details of the transaction into the reject table 74 (FIG. 2).

Assuming that the preprocessor and decomposer 54 successfully performsthe gathering of information for the decomposing of the transaction intosubtransactions appropriately, then control is returned to thetransaction processing controller 52, wherein this controller thenwrites the details of the transaction to the transaction journal 78along with identification data uniquely identifying the transaction(e.g., a transaction sequence number and/or time and date stamp).Following this, the transaction processing controller 52 invokes thesubtransaction scheduler 62 for scheduling the performance of eachsubtransaction by an invocation of the subtransaction processing module64. Note that it is an important aspect of the present invention thatsince the subtransactions can be processed independently of one anotherfor a given transaction, instantiations of the subtransaction processingmodule 64 can be executed in substantially any desired order. Inparticular, such instantiations of the subtransaction processing module64 can be performed concurrently, thus providing a substantial increasein transaction processing efficiency when such concurrency is providedon a computer having a plurality of processors.

Given that a subtransaction is performed successfully by thesubtransaction processing module 64, various accounting tables withinthe transaction processing system 50 are updated. In general, eachsubtransaction conceptually indicates a single operation of either plusor minus that is to be performed with two operands also indicated in thesubtransaction. That is, the first operand indicates the data to beadded or subtracted from a particular field or column of a table rowidentified by the second operand. Additionally, each subtransactionupdates other tables within the transaction processing system 50automatically in order to provide consistency among the data tables sothat: (a) substantially on-line account balancing capabilities can beperformed, and (b) full auditability of the records of the businessenterprise providing the transaction can be facilitated by retaininghistory records of table updates, as will be discussed with reference to“master table transaction cluster processing” described hereinbelow.Accordingly, each subtransaction processed by an instantiation of thesubtransaction processing module 64 may update a plurality of the datatables contained in the collectively labeled database 70. Note that forone skilled in the art of transaction data processing and accounting,the names provided to the tables are indicative of their informationcontent and structure. However, for clarity, substantially all of thetables for the present invention will be discussed in detail and/orillustrated hereinbelow.

The subtransaction processing module 64 processes subtransactionsderived from three general categories of transactions that may be inputto the present invention. That is, there may be input transactions foreach of the following types of financial transactions (1.1) through(1.3) hereinbelow.

(1.1) Transactions related to exchanges of funds such as cash debits andcredits for accounts of a particular business enterprise are provided.At a high level, the tables related to this functionality include theaccount master table 84 (FIG. 2), the general ledger table 88, and theentity attribute master table 92.

(1.2) Transactions related to additional or customized accounting forclients having accounts in the account master table 84 are provided. Forexample, in addition to providing the functionality of the transactionsdescribed in (1.1) immediately above, a customer income statement(income/expense) table 96 may be provided with client account andtransaction information related to income and expenses for tax purposes.Additionally, a customer cash flow (receipts/disbursements) table 100 isalso provided for recording any account transaction information relatedto receipts and disbursements in client accounts. Further, a customerperformance measurement table 104 is also provided for retaining clientaccount performance information related to the performance of clientportfolios in comparison to investment indexes such as the Dow JonesIndustrial Average, the S&P 500, etc. Note that these tables will bediscussed and/or illustrated hereinbelow.

(1.3) When transactions are additionally related to financialinstruments other than cash, debits and credits, such as portfoliomanagement wherein there is buying and selling of equities, incomederived from equities, and trade settlements related thereto. Further,note that these additional capabilities also provide the same degree offlexibility, adaptability and simplicity as provided in relation to thetransaction processing capabilities discussed in (1.1) and (1.2)immediately above. That is, financial equity transactions of varioustypes and for various business enterprises may be easily modified and/oradded or removed from the transaction processing system 50 of thepresent invention, since these transactions are also described bytransaction data descriptors consisting of a collection ofsubtransactions that are capable of being performed in substantially anyorder that is determined by the subtransaction scheduler 62.

Accordingly, in providing the functionality for the transactions relatedto portfolio management, the preprocessor and decomposer 54, upon beinginvoked by the transaction processing controller 52, also retrieves intoworking storage (as shown in FIG. 2) the necessary data for processingsuch portfolio maintenance transactions, this data including asubtransaction decomposition for the transaction. Subsequently, asdiscussed hereinabove, the subtransaction scheduler 62 invokes aninstance of the subtransaction processing module 64. However, inaddition to updating any appropriate rows of the tables 84, 88, 92, 96,100 and 104, the subtransaction processing module 64 invokes a portfolioadjuster module 110 for capturing and/or updating detailed data ofportfolio transactions that are not otherwise effectively captured forproper accounting and auditing. In particular, for a givensubtransaction, the portfolio adjuster 110 invokes one of the followingmodules (2.1) through (2.4) hereinbelow.

(2.1) Original add module 114 for processing a subtransaction related tothe addition of further financial instruments to a portfolio such asoccurs when securities are bought and must be added to a given account.

(2.2) A reverse of add module 118 for reversing an addition of financialenterprises to a particular account portfolio. Note that this module istypically activated when financial enterprises are inadvertently addedto an incorrect portfolio account.

(2.3) An original sell module 122 for processing subtransactions relatedto selling financial enterprises within a given account portfolio.

(2.4) A reversal of original sell module 126 for reversing the affectsof an inadvertent sell of financial enterprises within an accountportfolio.

These four modules 114- 26 update the tables labeled collectively as70B. In particular, the processing performed herein and the tablesupdated herein are described below.

Major Programs and Functionality

Major Programs

The N_gine transaction processing system contains four major programs.These are:

-   -   (1) Transaction Processing controller 52    -   (2) Transaction Preprocessor and Decomposer 54    -   (3) Subtransaction Processing module 64    -   (4) Subtransaction Scheduler 62        Program Functionality

The purpose of the Transaction Processing controller 52

-   -   (a) test for incoming transactions and once detected    -   (b) execute the Transaction Preprocessor and Decomposer 54 and        then    -   (c) execute the Subtransaction Processing module 64 for each        transaction.

The purpose of the Transaction Preprocessor and Decomposer 54 is toverify

-   -   (a) that all information in the transaction is accurate    -   (b) that all files and controls are available to properly        process the transaction    -   (c) that the specific subtransaction processing instructions are        loaded into working storage.

The purpose of the Subtransaction Processing module 64 is to

-   -   (a) execute all of the subtransactions that have been previously        defined for a transaction    -   (b) create auditability for every transaction.

The purpose of the Subtransaction Scheduler 62 is to

-   -   (a) allocate a specific task to a specific processor    -   (b) return processing to the Transaction Processing controller        52.

The present invention may be described as “Table-Driven TransactionProcessing”. That is, the present invention permits the processing ofvirtually any type of user-definable transaction by defining theprocessing for such transactions as data descriptors that areinterpreted in real time and dynamically as needed for processingcorresponding transactions. Accordingly, the transaction datadescriptors are denoted as “driving data” and are defined by thetransaction processing master table and the transaction master table.That is, the transaction master table provides a first initialcollection of data for identifying each transaction and the transactionprocessing table provides the remainder of the data including thesubtransaction decompositions. Accordingly, each transaction processedupdates an appropriate set of user-definable tables (known as the“driven” data) for completing the processing of the transaction. Sinceboth the “driving” and the “driven” information is expressed as datarather that actual code, the entire functionality of the system can bechanged in a straightforward manner.

In the description hereinbelow, the functional components of the presentinvention are also identified by other naming conventions from thedescription above. Accordingly, the following table shows the pairing ofthe functional component identifications above with those also usedbelow: ABOVE BELOW TRANSACTION PROCESSING CONTROLLER 52 N_GINE COMMANDPROCESSOR TRANSACTION PREPROCESSOR AND N_GINE EDIT PROCESSOR DECOMPOSER54 SUBTRANSACTION PROCESSING MODULE 64 N_GINE POSTING TO AM, EA AND GLSUBTRANSACTION SCHEDULER 62 N_GINE SCHEDULER PORTFOLIO ADJUSTER 110 AORSORIGINAL ADD MODULE 114 ORIGINATE ADD PROCESSING REVERSER OF ADD MODULE118 REVERSE ADD PROCESSING ORIGINAL SELL MODULE 122 ORIGINATE SELLROUTINE REVERSE OF ORIGINAL SELL MODULE 126 REVERSER SUBTRACT PROCESS

N_gine System Design Rules

A. The Magic Number in Software Design is 1. That is,

-   -   store data once,    -   program data once,    -   process data once.

B. Design a total system with the fewest number of processing models.For example,

-   -   One model for processing all adds (inserts), changes (updates),        and deletes (deletes) for all Master (or Reference) Files (or        tables).    -    Namely,        -   Begin Time        -   Number of Transactions        -   Number of Acceptances        -   Number of Rejects        -   End Time.

These variables represent the only true means of measuring actualproductivity.

F. For reasons of auditability, never overwrite any originalinformation. Move all original information from data entry (cradle) todata warehouse (grave) without any changes.

G. For reasons of reliability and profitability, system designs shouldfocus on a “large number of small programs” rather than a “small numberof large programs”. The result is not only ease of maintenance but alsothe ability to spread the small programs across a number of simultaneousprocessors.

H. For reasons of manageability, all system designs should embrace oneintegrated enterprise-wide standard naming convention for all files(tables), records (rows), and fields (columns).

I. For reasons of portability, use the fewest number of languagecommands to code the system. Avoid vendor and/or language extensions.

J. For reasons of flexibility, never hard code what can be table-driven.

N_gine Design Concepts

A. Only 4 Processing Models for Financial Services andTelecommunications Applications

-   -   1. Schema    -   2. Units, Debit/Credit    -   3. Assets/Liabilities    -   4. File Maintenance Routine

B. Table-Driven Transaction Processing for maximum flexibility

-   -   1. Number of Transactions    -   2. Name of Each Transaction and Unique Details    -   3. Processing Algorithms (at least 1, up to 20 depending upon        complexity)    -   4. Each algorithm has 3 components        -   a. Plus (P) or Minus (M)        -   b. Operand 1        -   c. Operand 2

C. 100% Auditability For Every Transaction by creating

-   -   1. a Detail Record containing all relevant data and    -   2. hash totals of three relevant fields in at least 3 other        tables.

D. The 3 relevant fields for calculating all hash totals are:

-   -   1. Cash    -   2. Units    -   3. Cost Basis

E. Basic Relational Database Management System Processing Concepts

-   -   1. Commit/Rollback    -   2. Row Level Locking    -   3. Indexing, ROWID    -   4. Stored Procedures    -   5. Shared Memory

F. Some Financial Services Accounting Systems are not permitted tocommingle funds. That is, separate accounting for both income andprincipal must be provided. Therefore, each account master must have adesignated “income posting code” to define the proper processing. Such acode might be: (I) Income Only, (P) Principal Only, (B) Both Income andPrincipal.

N_gine's Basic Tables

Licensee Profile (The Licensee “Reference” or “Master” Tables)

-   LM The License Master table contains the necessary information to    process any type of licensee using either single or multiprocessing    computers.-   LU The Licensee User Master identifies different users for the    disparate systems that may be processed simultaneously.-   LT The Licensee Account Type table contains the necessary    information to process any type of account be it for a pension trust    account, a communications account, or a corporate subsidiary.-   LD The Licensee Default Definition table the default definitions for    cash, units, and cost basis controls for total system control.-   LL The Licensee General Ledger Definition is a list of all of the    acceptable entries for the General Ledger. That is, it provides a    framework for processing any type of accounting controls for any set    of account types.-   LS The Licensee Diversification Scheme contains a three level    classification scheme for reporting an decision-making purposes for    any set of assets and liabilities.-   LP The Performance Measurement Group Master contains a three level    classification scheme for measuring the performance of different    investment groups.-   LN The Licensee Summary Name Master contains a list of the entries    on any type of Income Statement and Cash Flow Statement.-   LW The Licensee Wholesaler Master contains name, address, sales    volumes, etc. wholesalers of communications services.-   LR The Licensee Reseller Master contains name, address, sales    volumes, etc. for resellers of communications services.    Account Profile (The Customer “Reference” Tables)-   AO The Account Objectives Table contains the different types of    account objectives, such as income, growth, capital preservation,    etc.-   AL The Account Jurisdiction contains the different types of legal    relationships, such as broker, agent, trustee, advisor, etc.-   AJ The Account Jurisdiction contains the different types of legal    jurisdiction, such as federal law, state law, foreign law, etc.-   AR The Account Representatives Table houses the different    representatives, their names and communication addresses.-   AN The Account Registration Names is a list of legal names used in    security settlement.-   AM The Account Master table provides all of the necessary    information to process any type of account by linking the Account    Objective, Account Jurisdiction, Legal Capacity, Profit Center,    Account Representative, and Registration tables plus other relevant    data for reporting content and reporting cycles.-   AC The Account Communications Links links the Account Number for    Financial Services to the account numbers for communications    services so that all information can be contained in one reporting    scheme.

Transaction Profile (The “Driving” Tables)

-   TM The Transaction Master table provides all of the information to    process any type of transaction, excepting the specific processing    algorithms.-   TP The Transaction Processing table provides all of the specific    processing algorithms for any type of transaction master. The    Transaction Master and Transaction Processing tables provide all of    the necessary information to process any type of transaction.-   TR The Transactions—Recurring Table (TR) contains the necessary    information for automatically processing any type of transaction on    a recurring basis.

Entity Profile (The Entity “Reference” Tables)

-   EM The Entity Master table provides all of the necessary information    to process any type of financial entity.-   EA The Entity Attribute table joins all relevant diversification    (known as type, group, and class), general ledger (known as    accounting control numbers), and performance group (known as type,    group, and class) data into one table for only one access seek.-   ET The Entity Transaction table links specific transactions to    specific entities, such as BG (Buy Government) for a US Treasury    Note, BF (Buy Tax-Free) for a tax-free bond, BE (Buy Equity) for    common stocks, etc. Note: It is the correct assignment of such    transactions to such entities that permits the proper accumulation    of data for income tax purposes.

Licensee Status

-   SG The System General Ledger contains all of the information to    process any type of institutional accounting control.-   SJ The System Transaction Journal Table contains all of the    transactions and all of the details for each transaction for a    specific accounting period.-   ST The System Trade Settlement Table contains all of the    automatically generated offset transactions for Buys and Sells-   SS The System Summary Table contains a record for each execution of    the system with the Begin Time, End Time, Number of Total Records    Read, Number of Accepts, Number of Rejects, etc.-   SR The System Reject Table contains a list of all transactions    rejected for whatever reason.-   SC The System Transaction Count Table contains the number of each    type of transaction processed on any given transaction.

Customer Status (The “Driven” Tables)

-   CS The Customer Income Statement contains all revenues, expenses,    and profits or losses for all customer accounts.-   CF The Customer Cash Flow Statement contains all receipts and    disbursements for all customer accounts.-   CB The Customer Balance Sheet table contains all assets and    liabilities for all customer accounts.-   CG The Customer Capital Gains table contains all of the realized    capital gain details for all customer accounts.-   CI The Pending Income table contains all of the pending income, such    as interest or dividends, for all accounts.-   CA The Pending Capital Adjustments table contains all of the pending    capital adjustments, such as stock splits, stock dividends, mergers,    acquisitions, etc., for all accounts.-   CP The Performance Measurement contains all of the periodic    performance records for all customer accounts.

The Control Tables (The “System Balance” Tables)

Since every transaction is recorded in a detail record plus hashed tothree other control tables, the control values of cash, units, and costbasis are added to like values in the following control tables:

Account Master, System General Ledger, and Entity

Attribute tables.

For other reports such as the Income Statement and the Cash FlowStatements, the Performance Measurement table is used as a control tableinstead of the General Ledger.

The present invention includes four computational processing models(process models 1 through 4) for processing financial transactions andassuring full auditability and traceability.

The purpose of Process Model 1 (FIG. 5) is to create a singlemethodology for capturing, maintaining, and archiving the non-financialtransaction data including a master table (reference table, or schema)data for 100% auditability within a single software system. This modelprovides:

A current database 300 (FIG. 5)(for additions, negations andcorrections) and an archive database 304(Read Only)

Eight tables (i.e. tables 312, 316, 320, 324, 328, 332, 336 and 340, ofFIG. 5)

Number of Modifications

12 Control Fields per master table

A sequence number generator

A process flow methodology for add, change, and delete of data tablerows.

The operation of Process Model 1 is as follows:

1) Normal Updating to current database 300 Write to Write to Move MasterAdd to Change Delete Reject Accept to History Master Master Master AddIF Identifier Found X IF Identifier Not Found X X Change IF IdentifierNot Found X IF Identifier Found X X X Delete IF Identifier Not Found XIF Identifier Found X X X

-   2) Periodic updating to the archive database 304 at the end of a    pre-determined time period. That is,    -   (a) archive snapshots of the archive master 312 in the current        database 300 to the master in archive database 304;    -   (b) archive the archive history 332 in the current database 300        to the master history 340 in the archive database 304;    -   (c) purge the history table 332 in the current database 304.

The purpose of Process Model 2 (FIGS. 2A, 2B) is to create a singlemethodology for: capturing, maintaining, and archiving the financialtransaction data including: units, and debit/credits for one or moredisparate financial applications with 100% auditability, wherein theprocessing is performed by: (a) computing configurations containing anynumber of simultaneous processors, (b) decomposing each input financialtransaction into separate and independent subcomponents, (c) allocatingthe subcomponents across any number of multiple processors.

The methodology of process model 2 utilizes a data-driven transactionprocessing strategy, wherein the manner in which a transaction isprocessed is determined by retrieving appropriate control data forprocessing a given input transaction. Thus, the present model providesthe ability: (a) to process like systems (such as financial servicessystems) with different transaction definitions and accountingrequirements (such as commercial banking, broker/dealers, mutual funds,insurance systems) and different debits and credits and/or (b) unlikesystems (such as telecommunications systems) with disparate definitions(such as landline, wireless, satellite, cable systems) within thepresent invention at the same time.

The purpose of Process Model 3 (FIGS. 2A, 2B) is to create a singlemethodology for: capturing, maintaining, and archiving the financialtransaction data including: units, debits/credits, financial instrumentsfor one or more disparate financial applications with 100% auditabilitywithin a single software system on computing configurations containingany number of simultaneous processors, decomposing each disparatefinancial transaction into separate and independent subcomponents,allocating the subcomponents across any number of simultaneousprocessors, and processing the data with 100% auditability. Themethodology of Model 3 provides:

-   -   “Detail Record Maintenance”, that is, the ability to process        transactions for similar business enterprises (such as portfolio        management systems) relating to various financial instruments        (such as disparate assets and liabilities) and/or transactions        for dissimilar business enterprises (such as portfolio        management systems, paying agencies, stock transfer systems)        with disparate languages (such as English, Spanish, French, or        German) and disparate definitions (such as management        philosophy, accounting, and operating nomenclature) and unlike        financial instruments (such as assets and liabilities) within        the same software at the same time.    -   The ability to decompose, allocate, process, and audit each        financial instrument transactions with 100% auditability.    -   The current databases 300 (for additions, negations and        corrections) and the archive databases 304(read only);    -   Sixteen data tables (some of which are shown in FIGS. 2A-2B)        plus a sequence generator;    -   12 control fields appended to the master tables for tracing        master table changes;    -   One transaction three hash totals (mostly using AM, EA, and PM        tables);    -   4 currency fields;    -   Sequence number generation;    -   Reversing/reversed by detail;    -   Processing flow for additions, negations, and corrections.

The purpose of Process Model 4 is to create a single methodology forperforming file maintenance including: creating a record (row)containing the initial data in a file (table) or modifying the initialdata within an existing record (row) within a file (table) or deleting acurrent record (row) from a file (table) in any software application oncomputing configurations using simultaneous processors. Where the term,“Details”, hereinbelow represents the identity of the specific financialtransaction, the methodology of the process model 4 is provided byprograms such as the following: BEGIN   IF Trxn is “ADD” then     /* Test for Duplicate Add */     SELECT One or More Values from theDesired File (Table) into Working Storage     IF Error then       /* Add New Record */       INSERT INTO Reject Report       IF Error then        Message “INSERT Reject ADD”, Details         Goto Write RejectTable       ENDIF     ELSIF       /*  Increment Existing Record */      Increment One or More Data Values       UPDATE SET, Details      IF Error then         Message “UPDATE Error ADD”, Details        Goto Write Reject Table       ENDIF     ENDIF   ELSIF Trxn is“SUBTRACT” then     /*  Test for Valid Record */     SELECT One or MoreValue(s) from Existing Record     IF Error then       Message “SELECTError SUBTRACT”, Details       Goto Write Reject Table     ENDIF     /* Test for Valid Amounts */     IF One or More Amounts > One or MoreValues from Existing Record then       INSERT INTO Reject Report      IF Error then         Message “INSERT Reject SUBTRACT”, Details        Goto Write Reject Table       ENDIF     /*  Delete ExistingRecord */     ELSIF One or More Amounts = One or More Values fromExisting Record     AND  Special Deletion Criteria = TRUE then      DELETE Record       IF Error then         Message “DELETE Error”,Details         Goto Write Reject Table       ENDIF     ELSE       /* Decrement Existing Record */       Decrement One or More Values      UPDATE SET, Details       IF Error then         Message “UPDATEError SUBTRACT”, Details         Goto Write Reject Table       ENDIF    ENDIF   ELSE       /*  Invalid ADD or SUBTRACT Code */       INSERTINTO Reject Report       IF Error then         Message “INSERT RejectAORS”, Details         Goto Write Reject Table       ENDIF     ENDIF    Goto EOJ     <<Write Reject Report>>     ADD to Reject Table     IFError then       Message “INSERT Reject Table Error”, Details       STOP    ENDIF     <<EOJ>>       Null   ENDAccordingly, the methodology of process model 4 defines:

-   -   (a) A current database (for additions, negations and        corrections) and archive database (Read Only)    -   (b) ADD or SUBTRACT;    -   (c) Initial tests for values;    -   (d) Special deletion criteria;

(e) Tests for action;

-   -   -   INSERT or UPDATE;        -   DELETE or UPDATE;        -   INSERT INTO Reject Tables;            Processing Model 1:

Processing model 1 is a method for processing changes to files (ortables) denoted as master or reference tables (files) wherein thesetables retain fundamental information that is not derivable from othertables. In particular, processing model 1 processes changes to mastertables in an automated manner without losing historical financialinformation. Accordingly, 100% auditability of all data changes is ableto be achieved.

The method of achieving this goal uses an architecture denoted as“Master Transaction Cluster Processing” (MTCP). MTCP is based on thepremise of creating a logical flow of all original information from datacapture (data entry) to permanent data repository (data warehouse) byreplacing single master files (or tables) with a cluster of files (ortables). Therefore, MTCP addresses the complete life cycle of allinformation relevant to organizational decision-making. MTCP is targetedfor use in the automatic generation of program code for multiplelarge-scale real-time transaction processing applications (such assecurities trading, telecommunications billing, and work management) onmulti-processing computers (using 4, 8, 16, 32 processors), wherecontrol is not only an increasing complex issue but an absolutenecessity for future competition.

The circumstances leading to the invention of Master Transaction ClusterProcessing are:

-   -   a) Prior art financial transaction software architecture lacks        the ability to identify transactions by table, transaction date,        transaction number, and the person authorizing the transaction.    -   b) Prior art financial transaction systems typically use only        one table to contain all Master Information (i.e., non-derivable        information) and the data in this table is overwritten, thereby        losing historical information. Cases in point would be a record        of all of the past mailing addresses or processing instructions        for a specific customer.    -   c) Without 100% retention of an organization's vital        information, management has no idea of the accuracy of the        information being used for decision-making purposes.    -   d) The Year 2000 problem, know as Y2K, is proving that past        software applications designs have reached technological limits        and current maintenance costs are inordinately expensive.    -   e) Competitive pressures are mounting for higher quality        software with lower software development and maintenance costs.        Totally new architectures for applications software is in great        demand.    -   f) The ComputerWorld article, “Information: America's Favorite        Investment,” by Paul Strassman, ComputerWorld Magazine, Aug. 5,        1996, states that over 1100 companies are spending more on        automation annually than the net worths of their respective        companies.    -   g) The Standish Report as described in Development Patterns,        InfoWorld Magazine, Feb. 3, 1997, p. 56, states that the success        rate of Business Process Reengineering has increased from 16% in        1994 to only 27% in 1996.

Note, in the book “Oracle Design”, Ensor & Stevenson, O'Reilly Press, itis a recommended practice to compromise data retention rather thanachieve 100% auditability. Today's hardware costs suggest otherwise.

The advantages of the present invention over the approaches discussedabove are:

-   -   to provide 100% auditability which offers business management        the capability to exercise its fiduciary responsibility to its        stockholders and Board of Directors,    -   to capture, maintain, and ensure the integrity of all vital        information for business enterprise decision-making purposes,        and    -   to preserve such information consistent with business        enterprise-defined data retention cycles. Additionally, the        present invention allows accountants to certify in business        enterprise annual reports that all vital corporate data is being        properly preserved.

A detailed description of Master Transaction Cluster Processingcorresponding to model 1 (the first computational model of the presentinvention) is as follows.

MTCP Overview

Master Transaction Clustering, or MTCP, performs the following tasks:

-   -   a) assigns a unique identifier based on (i) master table        identification, (ii) transaction date, (iii) transaction number,        and (iv) authorized user, to each transaction that causes a        change in the state of a particular record of a master table.        That is, if one or more data elements in the record change, then        the previous record is written to history, and a new status is        assigned to an identifier field used for tracking such changes;    -   b) creates a logical flow of data as it is originally entered        from its inception (data entry) to its repository (data        warehouse). The unique architecture of MTCP replaces the Master        File (or Table) within prior art systems with a cluster of        Master Files (or Tables), known as a “Master Transaction        Cluster”. This cluster is suitable for multiprocessing (or the        use of simultaneous processors within a single computer to        complete a common job). Hence, MTCP addresses 100% auditability        via maintaining the total life cycle of information. Aged        information may be deleted from the appropriate tables        consistent with user-defined data retention policies;    -   c) offers a standard for processing all Master Tables within a        total application;    -   d) provides a test bed for separately testing each Master Table        Cluster under development and all Master Table Clusters in        concert;    -   e) permits management to report that it is successfully        capturing, maintaining, and preserving all critical information        for decision-making purposes.        MTCP Scope

Master Transaction Cluster Processing utilizes the following (FIG. 5):

-   -   a) two databases (i.e., the current data base 300 and the        archive data base 304),    -   b) sequencing generator 308 having: (i) two external sequence        generators; (ii) two internal counters,    -   c) eight tables (denoted master table 312, input table 316,        summary table 320, reject table 324, accept table 328, history        table 332, master archive table 336 and master history table        340), and    -   d) twelve additional fields for every row in the master table        312.        MTCP Independence

Master Transaction Cluster Processing of Model 1 is independent of any:

-   -   a) application—such as accounts receivable, customer billing,        etc.    -   b) industry—such as financial services, telecommunication, or        work management,    -   c) hardware manufacturer—such as Compaq, Digital, HP, IBM, NCR,        Unisys,    -   d) operating system—such as MS-DOS, UNIX, OpenVMS, MVS, etc.    -   e) network—such as Novell, Ethernet, etc.    -   f) relational database management system—such as Oracle, Sybase,        Microsoft SQL Server, Informix, etc., and    -   g) computer language—such as SQL, COBOL, FORTRAN, PL/1, Java,        etc.        MTCP Architecture

The Master Transaction Cluster Processing (MTCP) architecture can beused for any application in any industry using any computer language.Within the typical structured processing scheme of input and process,the Master Transaction Cluster Processing focuses solely on the processfunction. Thus, the method permits users to define input screens anddefined output reports.

MTCP Databases

Unlike prior art software system which contain only one table for eachset of primary records, Master Transaction Cluster Processing uses eightrelated tables, or a cluster of tables, to track all information on acradle to grave basis. The cradle being its point in inception (or dataentry), and the grave being its permanent repository (or datawarehouse). Consequently, the “Master Transaction Cluster” spans twodifferent databases: one denoted the Current database 300 containing allrelevant data for the current processing period and a second denoted theArchive database 304 containing all relevant data for all previousprocessing periods. The Current database 300 represents the area of highinquiry, and the Archive database 304 represents the area of lowinquiry. Consequently, the Current database 300 is normally placed onhigh-speed internal disk drive and the Archive database 304 is normallyplaced on less expensive lower-speed CD-ROMs. Note that trailinginformation in the Archive database 304 may be destroyed consistent withdefined data retention policies, statute of limitations, etc.

MTCP Tables

The six tables in the Current database 300 are the

-   -   a.) Master Table 312(M) that will contain all records to be        maintained.    -   b.) Input Table 316 (I) that will contain all records prior to        updating.    -   c.) Reject Table 324 (R) that will contain all records rejected        during processing.    -   d.) Accept Table 328 (A) that will contain all records accepted        during processing.    -   e.) History Table 332 (H) that contain a complete snapshot of        all records prior to updating.    -   f.) Summary Table 320 (S) that contains the results of a        specific processing operation.        and the two tables in the Archive database 304 are the:    -   g.) Master Archive Table 336 that contains snapshots of the        master table 312 at the end of each processing period.    -   h.) Master History Table 340 that contains a history of the        master table 312 changes during a current processing period.

Note that the Master Table (M), Input Table (I), Reject Table (R), theAccept Table (A), the History Table (H) in the same “Master TransactionCluster” share the same number and order of data elements consisting ofalphabetic, numeric, and date items. Alternatively, the Summary Table(S) contains the start time, end time, number of accepts, and number ofrejects for each time a series of master table 312 modifications areprovided.

MTCP Generator and Counters

The Generators 308 include two different external counters and twointernal counters used in effecting 100% auditability. The two externalcounters are the Accept Sequence Number Generator and the RejectSequence Number Generator. The two internal counters are the TotalRecords Read Counter and the Number of Modifications Counter. All areused only in the Current database 300, as the Archive database 304 isread-only in nature.

Regarding the external counters, the Accept Sequence Number Generatorincluded in the Current database 300 automatically generates sequentialnumbers for the processing period (daily, weekly, monthly, etc.)starting with the number 1, and increments by 1, so that everytransaction processed against the preceding (old) master table 312 willreceive a specific transaction number, and accordingly, each transactionprocessed will be uniquely identifiable based on master table identity,transaction date, transaction number, and authorized user. Note that thetransaction date is read off the internal system clock. The RejectSequence Number Generator counts the number of rejects for the specificprocessing period. Its function is similar to the Accept Sequence NumberGenerator. Both the Accept Sequence Number Counter and the RejectSequence Number Counter are “processing period” specific. That is, bothare cleared to zero at, e.g., midnight on the end of the processingperiod so that each processing period may be separately identified andaudited.

Regarding the internal counters, the Total Records Read Counter countsthe number of transactions read during a specific processingperformance. Since the Total Records Read Counter is “job execution”dependent, this counter is cleared to zero at the outset of everyprocessing program execution. The Number of Modifications Counter countsthe number of times a specific record has been changed. As this counteris “record” dependent, this counter is never cleared to zero, Thisspecific counter should identify the number of individual records thatmay be retrieved, viewed, and

To achieve 100% auditability of a complete system, every master file (ortable in relational database management systems has a Master TransactionCluster. Therefore, a total system containing 15 tables would require15×8 or 120 tables to achieve full 100% auditability. Since each tablewill require at least 4 SQL scripts to (1) Create Table, (2) Select datafrom the table, (3) Delete data from the table, and (4) Drop the Tablein the event of redefinition, the number of SQL scripts is 15×8×4, or960 SQL Scripts. Then, each Master Transaction Cluster will require atleast a Processing Program plus a Review, Reset, and Retest, or at leastfour more programs for each cluster, or 4×15, or 60, more SQL Scripts.All of the SQL scripts would be stored in one SQL Script Library on thecomputer for future reference and ease of maintenance.

MTCP Multi-processing

The multi-processing of the Master Transaction Cluster occurs in thefollowing manner:

For additions (or Insertions in SQL) of data

-   -   The Insertions to the Master Table 312 and    -   Insertions to the Accept Table 328 may be processed        simultaneously.

For changes (or Updates in SQL) of data

-   -   The Update of the Master Table 312 and the Insert to the Accept        Table 328 may be processed simultaneously after the original        record from the Master Table 312 has been copied to the History        Table 332.

For deletes (or Deletes in SQL) of data

-   -   The Deletion from the Master Table 312 and the Insertion to the        Accept Table 328 may be processed simultaneously after the        current record in the Master Table 312 has been updated for the        transaction identifier and then copied to the History Table 332.        MTCP Creation

Before processing any Master Transaction Cluster, the necessarydatabases and files (or tables) must be created. For each businessenterprise utilizing the present invention, these databases and filesare created only once in the following manner: (Begin Program)   Create”Current” database   Create ”Archive” database   in the ”Current”database     Create Master Table     Create Input Table     CreateReject Table     Create Accept Table     Create Second Accept Table (onseparate     disk unit, if desired)     Create History Table     CreateSummary Table   Create Sequence Number for Accepts   Create SequenceNumber for Rejects   in the ”Archive” database     Create Master Archive    Create History Archive (End of Program)MTCP Processing

Processing of the “Master Transaction Cluster” then occurs in thefollowing manner.

-   Step 1: All required information for processing a transaction is    first captured on an Input Form.-   Step 2: Once this information is edited by, e.g., an operator, an    Enter Key can be pressed by an operator to write this information to    the Input Table 316 for particular master transaction clusters.-   Step 3: For each input table 316, a polling program notes that the    Input Table is not empty and has a transaction action to be    processed whereupon the action is processed by a process (denoted    “process 1” in FIG. M1).-   Step 4: The transaction processing program determines the type of    file maintenance to perform; basically,    -   (1) add a record (entitled Insert a Row in SQL),    -   (2) change a record (entitled Update a Row in SQL), and    -   (3) delete a record (entitled Delete a Row in SQL),        which in turn determines the multi-processing potential as        described above in the MTCP Multi-processing.

The normal daily processing flow to achieve 100% auditability in eitherreal-time or batch mode is as follows:   (Begin Program)   Read SystemClock to Store Begin Time   (Read Next Transaction)   If LastTransaction     Read System Clock to Store End Time     Write End Time,Begin Time, Number of Accepts, Number of Rejects,       and TotalRecords Read to Summary Table     Goto End of Program   Increment TotalRecords Read by 1   (Add a New Record)   If transaction is ”Add“ then    If record exists then       Process Addition Error       Goto WriteReject Table   ********************************************************    * Select System Clock Date into Insert - Transaction Date *     *Increment Sequence Number into Insert - Transaction Number *     *Select User Name into Insert - Transaction User *     * Select Zero intoUpdate - Transaction Number *     * Select Zero into Delete -Transaction Number *  *********************************************************     Insertto Master Table     Goto Write Accept Table     (Change an ExistingRecord) If transaction is ”Change“ then     If record does not existthen       Process Change Error       Goto Write Reject Table  *********************************************************   * (MasterSnapshot) *   * Move Master Table Record to History Table *  *********************************************************   * SelectSystem Clock Date into Update - Transaction Date *   * IncrementSequence Number into Update - Transaction Number *   * Select User Nameinto Update - Transaction User *   * Select Zero into Delete -Transaction Number *   * Increment Master Table Number of Modificationsby 1   *   *********************************************************  Update Master Table with New Data   Goto Write Accept Table (Delete anExisting Record)   If transaction is ”Delete“ then     If record doesnot exist then       Process Drop Error       Goto Write Reject Table  *********************************************************     * SelectSystem Clock Date into Delete - Transaction Date  *     * IncrementSequence Number into Delete - Transaction Number *     * Select UserName into Delete - Transaction User   *  *********************************************************     * UpdateMaster Table Record for Tran Date/Tran Num/User    *  *********************************************************     *(Master Snapshot)          *     * Move Master Table Record to HistoryTable        *  *********************************************************     DeleteMaster Table Record From Master Table     (Write MULTI-PROCESSED AcceptTable)   ****************************************     * Move ”Current“into Archive - Status *     * Move ”System Date“ into Archive - Date  *  ****************************************     Increment Accept Counter    Insert to Accept Table     Insert Second Accept Table (on a separatedisk drive, if desired)     Goto Loop to Next Transaction   (WriteReject Table)       Increment Reject Counter       Insert to RejectTable   (Loop to Next Transaction)       Goto Read Next Transaction  (End of Program)       End

-   Step 5: At the end of the “proofing period”, such as daily or    weekly, when proof tallies are matched to computer tallies, the    Accept Table can be deleted as follows:    -   (Begin Program)    -   Delete All Records from the Accept Table    -   (End Program)-   Step 6: Backup all databases and tables before any information is    purged as follows:    -   (Begin Program)    -   Write All Tables in the “Current” database to backup    -   Write All Tables in the “Archive” database to backup    -   (End of Program)

Step 7: At the end of a user-defined period, an archive and purgeprocess occurs that (Begin Program)**************************************** * Move ”Archive“  to ArchiveStatus * Move ”System Date“ to Archive Date**************************************** Move All Records in the MasterTable to Master Archive. Move All Records in the History Table to theHistory Archive. (End Program)

-   Step 8: In the event that current records are wrongfully moved to    the History Archive,    -   they may be retrieved by        -   (Begin Program)    -   Move Specific Records from the Master Archive to the Master        Table        -   Move Specific Records from the History Archive to the            History Table    -   (End Program)        This program should be executed only after Records have been        moved from the Current database 300 to the Archive database 304.        It should never be run after new transactions have been        processed to the Current database 300.        MTCP Backup/Recovery

If necessary, a recovery program can be utilized at any time in theevent of hardware failure. Upon complete recovery, Step 7 and Step 8will have to be re-executed to insure the correct status before the nextday's processing is begun. The Accept Table can then be used to as asubstitute Input Table to return the system to its previous processingpoint. Once this table is exhausted, data from the Input Table wouldsupply the remaining data for the processing job.

MTCP Management

Once test data are defined and processed, a business enterprise may

-   -   (a) Review lists of the contents of all Master Tables 312 for        determining correctness.    -   (b) Reset the contents of all Master Tables for performing the        next test.    -   (c) Retest.        MTCP Auditability

Once auditabilty is achieved, the business enterprise may query:

-   -   (a) When a Master Table Cluster was created.    -   (b) When each record was added (or inserted) to the Master Table        312,    -   (c) How many authorized changes (or updates) have been made to a        record of the Master Table 312.    -   (d) Prove the integrity of the master transaction cluster by        producing a sequential list of all record changes, and if the        record was deleted, where the record is stored.        Accordingly, 100% auditability of every change, every day, for        every application is possible.        Multiprocessing Defined

Unlike serial processing which processes all jobs in sequential fashion,multiprocessing processes some of the same jobs simultaneously, or inparallel. While multiprocessing is not new, major computer manufacturerssuch as Compaq, Digital, Hewlett-Packard, IBM, NCR, Unisys, etc. haveannounced offerings of low-cost multiprocessing machines based on 2, 4,8, and sixteen processors. These machines will rapidly increase thedemand for multiprocessing software, which is known as “multithreaded”software. Multithreaded software permits the simultaneous execution ofmore than one jobs or job sequences.

Multiprocessing takes two forms, Symmetrical Multiprocessing (SMP) andMassively Parallel Processing (MPP), the difference being thatsymmetrical multiprocessing machines collectively have only one busbetween the processors and the peripheral storage. For example, asymmetrical multiprocessing machine may have eight processors, one bus,and sixteen disk drives. In contrast, massive parallel processingmachines has one bus for each processor. For example, a massivelyparallel machine may have eight processor, eight busses, and sixteendisk drives. Therefore, symmetrical multiprocessing machines are bestsuited for applications with a high processing content and a lowinput/out content. In contrast, massively parallel processing machinesare best suited for applications that can be parallelized and have ahigh input/output requirement, as is the case with many commercialsystems.

In either event, multiprocessing machines are best utilized whencarefully tuned to avoid bottlenecks. This is likely to mean that all ofthe layers constituting a computing environment aremultiprocessing-enabled. That is, the hardware, operating system,relational database management system, and the specific application arecapable of multiprocessing. Some multiprocessing mainframes have beenavailable for several years as well as some versions of the UNIXoperating system. Only a few multiprocessing relational databases existand even fewer multiprocessing applications. It is believed by some thatthe success of multiprocessing is solely dependent upon the “knowledgeof the application” rather than “knowledge of the underlying tools,” thetools being the hardware, operating system, and relational databasesystem.

Accordingly, it is believed that the limiting factors for the success ofmultiprocessing for financial systems depends on:

-   -   (1) the lack of financial transaction application knowledge,    -   (2) a lack of understanding of how multiprocessing can be used        to effect 100% auditability, and

The value of MTCP is that it addresses the last form of multiprocessingwhich is believed to be the most critical to delivering rapid responsetimes for real-time financial transaction processing systems. That is,by dividing a transaction into subtransactions that can be spread acrossseveral multiprocessors, processing throughput may be faster. Plus, thelarge number of small programs make maintenance much easier and lessexpensive.

A first embodiment of the transaction processing controller 52 isprovided in the flowchart of FIG. 6. Note that for simplicity, errorhandling and related validity checking steps have been omitted. However,the performance of such steps is within the scope of the presentinvention, as one skilled in the art will appreciate. A secondpseudo-code embodiment of the transaction processing controller 52follows.

Pseudo-Code for the Command Processor (Transaction Processing Controller52)

BEGIN   /* The following switches are global. They control both theactivity of the system.  */   /* The Processor Switches monitors theavailability of an eight processor computer.  */   /* The ProcessSwitches monitors all of the jobs that are to be executed. */   /* Theseswitches initialize the system, and then change throughout processing */   /* as the subcomponents of the system and the processors finish.*/   /* The Processor Switches are turned ON as jobs are sent tospecific processors.  */   /* The Processor Switches are turned OFFafter the jobs are completed.  */   Set Processor 1 Switch = 0   SetProcessor 2 Switch = 0   Set Processor 3 Switch = 0   Set Processor 4Switch = 0   Set Processor 5 Switch = 0   Set Processor 6 Switch = 0  Set Processor 7 Switch = 0   Set Processor 8 Switch = 0   Read BeginTime from Systems Clock into Working Storage   Set Total Records Read =0   Set Number Accepts  = 0   Set Number Rejects  = 0   /* The CommandPrograms reads the transaction input from the operator, then */   /*edits the transaction for validity and loads the transaction processingalgorithms */   /* from the Transaction Processing table (or cache file)to a temporary table. It then */   /* walks down all of algorithms inthe temporary table to process the total transaction */   /* with 100%auditability. Each algorithm may be passed to a separate processor.   /*Read operator instructions for starting and ending item in input stream    */   /* For the purposes of restart in the event of mid-stream jobfailure */   /* For the purpose of omissions in processing. */   /*  Operator may enter Begin .......................... End for all items*/   /*   Operator may enter Begin ..... End    for a beginning list */  /*   Operator may enter   Begin ..... End      for an intermediatelist */   /*   Operator may enter     Begin ..... End for an ending list*/   Read Beginning Item in Input Stream from Master Control Terminal  Read Ending Item  in Input Stream from Master Control Terminal   SetBeginning Item  to Next Transaction   Set Ending Item  to End of List  Read System Clock for Begin Time   Add Record with Begin Time   IFError then     Message “No System Table Record for Begin Time”, Details  ENDIF   <<Read Next Transaction>>   /* The Process Switches are turnedON as each transaction subcomponent is completed.  */   /* The ProcessSwitches are turned OFF after the total transaction is completed.   */  Set Process  1 Switch = 0   Set Process  2 Switch = 0   Set Process  3Switch = 0   Set Process  4 Switch = 0   Set Process  5 Switch = 0   SetProcess  6 Switch = 0   Set Process  7 Switch = 0   Set Process  8Switch = 0   Set Process  9 Switch = 0   Set Process 10 Switch = 0   SetProcess 11 Switch = 0   Set Process 12 Switch = 0   Set Process 13Switch = 0   Set Process 14 Switch = 0   Set Process 15 Switch = 0   SetProcess 16 Switch = 0   Set Process 17 Switch = 0   Set Process 18Switch = 0   Set Process 19 Switch = 0   Set Process 20 Switch = 0   SetProcess 21 Switch = 0   Set Process 22 Switch = 0   Set Process 23Switch = 0   Set Process 24 Switch = 0   Read Next Transaction intoWorking Storage   IF EOF then     Read End Time from Systems Clock intoWorking Storage     INSERT End-time, Begin Time       Total RecordsRead, Number Accepts, Number Rejects       into Summary Table     IFError-then       Message “INSERT ST Table”, Details       STOP     ENDIF    Goto EOJ   ENDIF   IF Next Transaction = End of List     Goto EOJ  ENDIF   Increment Total Records Read   <<Test Transaction Type>>   IFTransaction Type != ‘ ‘ then   /* Set Switches for Trade Offset andSettle Offset Processing    */     Set Process  1 Switch = 0     SetProcess  2 Switch = 1     Set Process  3 Switch = 1     Set Process  4Switch = 1     Set Process  5 Switch = 1     Set Process  6 Switch = 0    Set Process  7 Switch = 1     Set Process  8 Switch = 1     SetProcess  9 Switch = 1     Set Process 10 Switch = 1     Set Process 11Switch = 0     Set Process 12 Switch = 1     Set Process 13 Switch = 1    Set Process 14 Switch = 1     Set Process 15 Switch = 1     SctProcess 16 Switch = 1     Set Process 17 Switch = 0     Set Process 18Switch = 0     Set Process 19 Switch = 1     Set Process 20 Switch = 1    Set Process 21 Switch = 1     Set Process 22 Switch = 1     SetProcess 23 Switch = 1     Set Process 24 Switch = 0   ENDIF   <<TestOORR>>   IF OORR = ‘O’ then     *****************     CALL N_gine EDIT    *****************     IF Edit Error       Message “Edit Error”,Details       Goto Write Reject Table     ENDIF     IF Tran-Type !=‘Sell’     OR Tran-Type != ‘Withdraw’ then       INSERT into TransactionJournal Table       IF Error         Message “Insert TJ Error”, Details        Goto Write Reject Table       ENDIF       IF Correction Datathen         DELETE from Reject Table         IF Error           Message“Delete Reject Error”, Details           Goto Write Reject Table        ENDIF       ENDIF     ENDIF     *********     CALL TT     i.e.,execute the algorithms in the temporary table     *********     IFTemporary Table Error then       Message “Temporary Table Error”,Details       Goto Write Reject Table     ENDIF     Generate SequenceNumber   ELSIF OORR = ‘R’     *****************     CALL N_gine EDIT    *****************     IF Edit Error       Message “Edit Error”,Details       Goto Write Reject Table     ENDIF     Assign TransactionNumber = ‘000000’     Assign LOT Number   = 1     <<Read Next Reversal>>    Read Transaction Journal Table for reversal number     IF “NoTransaction Exists” where LOT = 1 then       Message “No TransactionExists”, Details       Goto Write Reject Table     ENDIF     IF “NoTransaction Exists” and LOT> 1 then       Goto Transaction Wrap-up    ENDIF     IF Previously Reversed       Message “PreviouslyReversed”, Details       Goto Write Reject Table     ENDIF     INSERTReversing Transaction” to Transaction Journal Table     IF Error      Message “INSERT TJ Reversing Error”, Details       Goto WriteReject Table     ENDIF     UPDATE “Reversed” Transaction     IF Error      Message “”UPDATE TJ Reversed Error”, Details       Goto WriteReject Table     ENDIF     Increment the LOT Number     *********    CALL TT    i.e., execute the algorithms in the temporary table    *********     IF Temporary Table Error then       Message “TemporaryTable Error”, Details       Goto Write Reject Table     ENDIF     GotoRead Next Reversal     Generate Sequence Number     UPDATE “Reversed”Transaction, ALL ROWS with Reversing Data     IF Error then      Message “UPDATE TL Table Reversed”, Details       Goto WriteReject Report     ENDIF     UPDATE “Reversing” Transaction, ALL ROWSwith Reversed Data     IF Error then       Message “UPDATE TL TableReversing”, Details       Goto Write Reject Report     ENDIF   ELSE    INSERT into Reject Table “No Originate or Reverse Code”     IF Errorthen       Message “Insert Reject Table”, Details       Goto WriteReject Table     ENDIF   ENDIF   <<Transaction Wrap-up>>   INSERT INTOTransaction Count Table   Select Original-Count and Reversal Count fromTC Table into Working Storage   IF Error then     INSERT INTO TC Table,Details     IF Error then       Goto Write Reject Table     ENDIF   ELSE    IF AORS = ‘O’ then Increment Original-Count     ELSIF AORS = ‘R’Increment Reversal-Count     ELSE Message “Invalid AORS Code”, DetailsSTOP     ENDIF   ENDIF   <<Test Trade Settlement>>   IF TransactionSwitch = 2 Goto Loop Next Transaction   ENDIF   IF Transaction Switch =1   OR AORS = ‘‘ then Goto Loop Next Transaction   ENDIF   /* COMMITWork to Database     */   COMMIT Original Transaction Before OffsetTransaction   IF AORS = ‘A’ then Insert Licensee Trade Offset Buy inTransaction Identifier   ELSIF AORS = ‘S’ Insert Licensee Trade OffsetSell in Transaction Identifier   ELSE Message “Invalid AORS”, Details  ENDIF   /* Swap Account Numbers for Automatic Transaction   */   MoveAccount Number to Working Storage Account Number   Move Buyer/SellerNumber to Account Number   Move Working Storage Account Number toAccount Number   Multiply the Net Amount by  −1   Multiply the AmountUnits by −1   Add Number of Settlement Days from Entity Master to TradeDate to determine Settlement Date   Add to Total Number of Accepts  UPDATE Row in System Table for Number of Accepts   IF Error then    Message “Update Error for Accepts”, Details     Goto Write RejectRecord   ENDIF   Go to Test Transaction Type   <<Loop Next Transaction>>  /* COMMIT Work to Database     */   COMMIT Original Transaction orOffset Transaction, if any   Goto Read Next Transaction   <<Write RejectRecord>>   Add to Total Number of Rejects   UPDATE Row in System Tablefor Number of Rejects   IF Error then     Message “Update Error forRejects”, Details   ENDIF   INSERT Into Reject Table, Details   IF Error    Message “Insert Command Reject Table”, Details     STOP   ENDIF  Move Incoming Licensee Identifier to Stored Licensee Identifier   MoveIncoming Account Identifier to Stored Account Identifier   Move IncomingTransaction Identifier to Stored Transaction Identifier   Move IncomingEntity Identifier to Stored Entity Identifier   Goto Read NextTransaction   <<EOJ>>   Read System Clock for End Time   Add Record withEnd Time   IF Error then     Message “No System Table Record for EndTime”, Details   ENDIF END

A first embodiment of the transaction preprocessor and decomposer 54 isprovided in the flowcharts of FIGS. 7-A through 7-D and FIGS. 8-A and8-B. Note that for simplicity, error handling and related validity checksteps have been omitted. However, the performance of such steps iswithin the scope of the present invention, as one skilled in the artwill appreciate.

A second pseudo-code embodiment of the transaction preprocessor anddecomposer 54 follows.

Pseudo-Code for the Edit Processor for all Incoming Transactions(Transaction Preprocessor and Decomposer 54)

BEGIN   Housekeeping     Set Working Storage Alphas to Blanks     SetWorking Storage Numbers to Zeroes   IF Incoming Licensee Identifier =Stored Licensee Identifier then     Using Licensee Identifier from InputString, retrieve       Licensee Name       Trade Settlement Switch      Trade Offset Buy       Trade Offset Sell       from LicenseeMaster into Working Storage     IF Error then       Message “No LicenseeMaster”, Detail       Goto EOJ     ENDIF   ENDIF  /***********************************************/   IF   the DefaultDefinition Table has not been loaded to memory then     LOAD all recordsfrom the Default Definition Table consisting of       Licensee       DDClass       DD Identification       DD Sub-Class       DD AccountingControl Number       DD Name         from the Default Definition Table        into the Temporary Table (TA)     IF Error then       Message“NO TA Table”, Details       Goto EOJ     ENDIF   ENDIF  /***********************************************************/   IF theIncoming Account Identifier = Stored Account Identifier     Goto AccessTransaction Master (TM)   ELSE     /*** This is the first tablecontaining control totals for cash, units, and cost basis ***/    <<Access Account Master>>     From the Account Master Table (TM)    using the Licensee Identifier from the Input String      and theAccount Identifier from the Input String, retrieve       Account Type      Income Posting Code       Income/Expense Switch      Receipt/Disbursement Switch       Performance Measurement Switch      Fiscal Year - Month       Fiscal Year - Day       Fiscal Year -Number Periods       Income Cash Balance       Principal Cash Balance      Invested Income       Invested Principal       Total Units -Assets       Liabilities       Total Units - Liabilities       and theRow Identification of the Account Master Record         from the AccountMaster Table (AM) into Working Storage     IF Error then       Report“Invalid Account Identifier”, Details       Goto Write Reject Report    ENDIF   ENDIF   <<Access Transaction Master>>   IF   the IncomingTransaction Identifier = Stored Transaction Identifier     Goto TestCash Entry in Entity Attribute Table   ELSE     Using the LicenseeIdentifier from the Input String      and the Transaction Identifierfrom the Input String       Transaction Name       Add or SubtractSwitch       Settlement Switch       and the Row Identification        from the Transaction Master Table (TM) into Working Storage    IF Error then       Message “Invalid Transaction Identifier”,Details       Goto Write Reject Report     ENDIF     IF AORS = ‘A’ then      Using the Licensee Identifier from the Input String        and theTrade Offset Buy from Working Storage, verify        the existence of aTrade Offset Buy in the TM Table       IF Error then         Message “NoTrade Offset Buy”, Details         Goto Write Reject Table       ENDIF    ELSE AORS = ‘S’ then       Using the License Identifier from theInput String        and the Trade Offset Sell from Working Storage,verify        the existence of a Trade Offset Sell in the TM Table.      IF Error then         Message “No Trade Offset Sell”, Details        Goto Write Reject Table       ENDIF     ELSE       Message“Invalid AORS Code”, Details       Goto Write Reject Report     ENDIF    <<Access Transaction Processing Table (TP)>>     Using the LicenseeIdentifier from the Input String      and the Transaction Identifierfrom the Input String, retrieve       ALL of the Transaction Processingalgorithms       from the Transaction Processing Table (TP)       into aTemporary Table (TT) in Working Storage     IF Error then       Message“No Transaction Processing Algorithms”, Details       Goto Write RejectReport     ENDIF     /*** This is the second control table containingcash, units, cost basis, liabilities, etc. ***/     <<Test Income CashPosting Controls>>     IF  the Working Storage Income Posting Code = ‘I’    OR the Working Storage Income Posting Code = ‘B’ then       Countthe number of IC entries in the TA table       <<Test Income Cash>>      IF count = 1 then       Using Licensee Identifier from the InputString        and the Class = ‘IC’       and the Sub-Class = ‘ ‘retrieve         Accounting Control Number from TA into Working Storage      IF Error then         Message “Invalid Income Cash ACN”, Details        Goto Write Reject Record       ENDIF       Using the LicenseeIdentifier from the Input String        and the Accounting ControlNumber in Working Storage, retrieve        Accounting Control Number        and the Row Identification from General Ledger Table (SG)      IF Error then         Message “Invalid Income Cash on SG”, Details        Goto Write Reject Report       ENDIF     ELSIF count = 2 then      Using the Licensee Identifier from the Input String       and theClass  = ‘IC’       and the Sub-class = ‘D’, retrieve         AccountingControl Number from TA into Working Storage       IF Error then        Message “Invalid Income Cash Demand ACN in TA”, Details        Goto Write Reject Report       ENDIF       Using the LicenseeIdentifier from the Input String       and the Accounting Control Numberin Working Storage, retrieve         Accounting Control Number        and the Row Identification from the General Ledger       IFError then         Message “Invalid Income Cash Demand in GL”, Details        Goto Write Reject Report       ENDIF       Using the LicenseeIdentifier from the Input String        and the Class  = ‘IC’        andthe Sub-class = ‘O’, retrieve        Accounting Control Number from TAtable into Working Storage       IF Error then         Message “InvalidIncome Cash Overdraft ACN in TA”,             Details         Goto WriteReject Report       ENDIF       Using the Licensee Identifier from theInput String        and the Accounting Control Number in WorkingStorage, retrieve         Accounting Control Number         and the RowIdentification from the General Ledger       IF Error then        Message “Invalid Income Cash Overdraft in GL”, Details        Goto Write Reject Report       ENDIF     ELSE       Message“Invalid Income Cash Count on DD”, Details       Goto Write RejectRecord     ENDIF   <<Test Principal Cash Posting Controls>>   ELSIF theWorking Storage Income Posting Code = ‘P’     Count the number of PCentries in the TA table     <<Test Principal Cash>>     IF count = 1then       Using the Licensee Identifier from the Input String       and the Class = ‘PC’        and the Sub-Class = ‘ ‘ retrieve        Accounting Control Number from TA into Working Storage       IFError then         Message “Invalid Principal Cash ACN”, Details        Goto Write Reject Record       ENDIF       Using the LicenseeIdentifier from the Input String        and the Accounting ControlNumber in Working Storage, retrieve        Accounting Control Number        and the Row Identification from General Ledger Table (SG)      IF Error then         Message “Invalid Principal Cash on SG”,Details         Goto Write Reject Report       ENDIF     ELSIF count = 2then       Using the Licensee Identifier from the Input String       andthe Class  = ‘PC’       and the Sub-class = ‘D’, retrieve        Accounting Control Number from TA into Working Storage       IFError then         Message “Invalid Principal Cash Demand ACN in TA”,            Details         Goto Write Reject Report       ENDIF      Using the Licensee Identifier from the Input String       and theAccounting Control Number in Working Storage, retrieve        Accounting Control Number         and the Row Identificationfrom the General Ledger       IF Error then         Message “InvalidPrincipal Cash Demand in GL”, Details         Goto Write Reject Report      ENDIF       Using the Licensee Identifier from the Input String      and the Class  = ‘PC’       and the Sub-class = ‘O’, retrieve      Accounting Control Number from TA table into Working Storage      IF Error then         Message “Invalid Principal Cash OverdraftACN in TA”.             Details         Goto Write Reject Report      ENDIF       Using the Licensee Identifier from the Input String       and the Accounting Control Number in Working Storage, retrieve        Accounting Control Number         and the Row Identificationfrom the General Ledger       IF Error then         Message “InvalidPrincipal Cash Overdraft in GL”, Details         Goto Write RejectReport       ENDIF     ELSE       Message “Invalid Principal Cash Counton DD”, Details       Goto Write Reject Record     ENDIF   ELSE    Message “Invalid Posting Code”, Details     Goto Write Reject Report  ENDIF ENDIF <<Test Cash Entry in Entity Attribute Table>> Using theLicensee Identifier from the Input String  and the Account ControlNumber from the TU Record in Working Storage, retrieve   The TotalUnits - Assets   and the Row Identifier from the Entity Attribute Table(EA) IF Error then   Message “Invalid Total Units”, Details   Goto WriteReject Table   ENDIF   <<Test Asset / Liability Processing>>   IFWorking Storage Add or Subtract Switch (AORS; is OFF then     Goto EOJ  ENDIF   IF Incoming Entity Identifier = Stored Entity Identifier then    Goto EOJ   ENDIF   /*** This is the third table containing controltable for cash, units, cost basis, liabilities, etc. ***/   <<AccessEntity Attribute Table (EA)>>     Using the Licensee Identifier from theInput String      and the Entity Identifier from the Input String,retrieve       Accounting Control Number (Asset)       AccountingControl Number (Liability)       Diversification Type      Diversification Group       Diversification Class       InvestedIncome Balance       Invested Principal Balance       Total Units -Assets       Total Units - Liabilities       and the Row Identificationof the Entity Attribute Record         from the Entity Attribute Table(EA) into Working Storage     IF Error then       Message “InvalidEntity Identifier in EA”, Details       Goto Write Reject Table    ENDIF   <<Access the Entity Transaction Table (ET)>>     Using theLicensee Identifier from the Input String      and the Entity Identifierfrom the Input String, verify       the existence of an acceptabletransaction       in the Entity Transaction Table (ET) for the EntityIdentifier.     IF Error then       Message “Invalid Transaction forthis Entity”, Details       Goto Write Reject Table     ENDIF    <<Access the Entity Master Table (EM)>>     Using the EntityIdentifier from the Input String, retrieve       Income Rate      Income Ex-Date       Income Record Date       Income Payment Date      Cap-Adj Rate       Cap-Adj Ex-Date       Cap-Adj Record Date      Cap-Adj Payment Date       Settlement Days       Current Price        from the Entity Master Table (EM) into Working Storage     IFError then       Message “No Entity Master”, Details       Goto WriteReject Report     ENDIF   <<Test Other Assets>>     Using the LicenseeIdentifier from the Input String      and the Account Type from WorkingStorage      and the Accounting Control Number - Asset from WorkingStorage, retrieve       the Accounting Control Number - Asset       andRow Identifier from the General Ledger (SG)     IF Error then      Message “Invalid ACN - Asset”, Details       Goto Write RejectReport     ENDIF   <<Test Other Liabilities>>     Using the LicenseeIdentifier from the Input String      and the Account Type from WorkingStorage      and the Accounting Control Number - Liability from WorkingStorage, retrieve       the Accounting Control Number - Liability      and Row Identifier from the General Ledger (SG)     IF Error then      Message “Invalid ACN - Liabilities”, Details       Goto WriteReject Report     ENDIF   <<Test Invested Income>>     Using theLicensee Identifier from the Input String      and the Account Type Codefrom Working Storage      and the Invested Income Identifier fromWorking Storage, retrieve       the Invested Income Balance       andthe Row Identifier from the General Ledger Table (SG)     IF Error then      Message “Invalid Invested Income”       Goto Write Reject Table    ENDIF   <<Test Invested Principal>>     Using the LicenseeIdentifier from the Input String      and the Account Type Code fromWorking Storage      and the Invested Principal Identifier from WorkingStorage, retrieve       the Invested Principal Balance       and the RowIdentifier from the General Ledger Table (SG)     IF Error then      Message “Invalid Invested Principal”       Goto Write Reject Table    ENDIF     Goto EOJ   <<Write Reject Table>>     Add to Reject Table    IF Error then       Message “Invalid Insert to Reject Table”,Details       STOP     ENDIF   <<EOJ>>     Null END

Pseudo-Code for the SCHEDULER (Subtransaction Scheduler 62)

BEGIN <<Read Next Process>> Read Next Transaction in Temporary Table(TT) IF EOJ then <<Test All Switches - AORL>> IF All 18 Process Switches= 0 Goto EOJ ENDIF Wait 10 milliseconds Goto Test All Switches - AORLENDIF <<Test Processor Availability>> IF Processor 1 Switch = 0 then SetProcessor 1 Switch = 1 Initiate Process on Processor 1 @ end, SetProcessor 1 Switch = 0 Goto Next Process Loop ENDIF IF License Master(LM) Number of Processors = 1 then <<Test 1 Processor>> IF Processor 1Switch = 1 then Wait 10 Milliseconds Goto Test 1 Processor ENDIF GotoTest Processor Availability ENDIF IF Processor 2 Switch = 0 then SetProcessor 2 Switch = 1 Initiate Process on Processor 2 @ end, SetProcessor 2 Switch = 0 Goto Next Process Loop ENDIF IF License Master(LM) Number of Processors = 2 then <<Test 2 Processors Busy>> IFProcessor 1 Switch = 1 AND Processor 2 Switch = 1 then Wait 10milliseconds Goto Test 2 Processors Busy ENDIF Goto Test ProcessorAvailability ENDIF IF Processor 3 Switch = 0 then Set Processor 3 Switch= 1 Initiate Process on Processor 3 @ end, Set Processor 3 Switch = 0Goto Next Process Loop ENDIF IF Processor 4 Switch = 0 then SetProcessor 4 Switch = 1 Initiate Process on Processor 4 @ end, SetProcessor 4 Switch = 0 Goto Next Process Loop ENDIF IF License Master(LM) Number of Processors = 4 then <<Test 4 Processors Busy>> IFProcessor 1 Switch = 1 AND Processor 2 Switch = 1 AND Processor 3 Switch= 1 AND Processor 4 Switch = 1 then Wait 10 milliseconds Goto Test 4Processors Busy ENDIF Goto Test Processor Availability ENDIF IFProcessor 5 Switch = 0 then Set Processor 5 Switch = 1 Initiate Processon Processor 5 @ end, Set Processor 5 Switch = 0 Goto Next Process LoopENDIF IF Processor 6 Switch = 0 then Set Processor 6 Switch = 1 InitiateProcess on Processor 6 @ end, Set Processor 6 Switch = 0 Goto NextProcess Loop ENDIF IF Processor 7 Switch = 0 then Set Processor 7 Switch= 1 Initiate Process on Processor 7 @ end, Set Processor Switch 7 = 0Goto Next Process Loop ENDIF IF Processor 8 Switch = 0 then SetProcessor 8 Switch = 1 Initiate Process on Processor 8 @ end, SetProcessor 8 Switch = 0 Goto Next Process Loop ENDIF IF Licensee Master(LM) Number of Processors = 8 then <<Test 8 Processors Busy>> IFProcessor 1 Switch = 1 AND Processor 2 Switch = 1 AND Processor 3 Switch= 1 AND Processor 4 Switch = 1 AND Processor 5 Switch = 1 AND Processor6 Switch = 1 AND Processor 7 Switch = 1 AND Processor 8 Switch = 1 thenWait 10 milliseconds Goto Test 8 Processors Busy ENDIF Goto TestProcessor Availability ENDIF <<Next Process Loop>> Goto Read NextProcess <<EOJ>> Null END

Process the Controls Process Routine in the Temporary Table (TT)

BEGIN IF OORR = “O” then Set Factor = + 1 ELSIF OORR = ‘R’ then SetFactor = − 1 ENDIF <<Total Units>> IF Operand 2 = ‘TU’ then (AMU)Process AM Units (EAU) Process EA Units (PMU) Process PM Units <<CashBalances>> ELSIF Operand 2 = ‘IC’ OR Operand 2 = ‘PC’ then (AMC) ProcessAM Income Cash Demand Income Cash Overdraft Principal Cash DemandPrincipal Cash Overdraft (EAC) Process EA Income Cash Principal Cash(GLC) Process GL Assets - Income Cash Demand Assets - Income CashOverdraft Assets - Principal Cash Demand Assets - Principal CashOverdraft Liab - Income Net Worth Liab - Principal Net Worth<<Investment Balances>> ELSIF Operand 2 = ‘II’ OR Operand 2 = ‘IP’ then(AMI) Process AM Invested Income Invested Principal (EAI) Process EACost (GLI) Process GL Assets - Actg Control Number Liab - Income NetWorth Liab - Principal Net Worth <<Other Customized InvestmentReporting>> ELSIF Operand 2 = ‘I’ and Report Request = ‘Y’ OR Operand 2= ‘E’ and Report Request = ‘Y’ then (IEE) Process IE (PME) Process PM<<Receipts/Disbursements>> ELSIF Operand 2 = ‘R’ and Report Request =‘Y’ OR Operand 2 = ‘D’ and Report Request = ‘Y’ then (IEC) Process RD(PMC) Process PM <<Performance Measurement>> ELSIF Operand 2 = ‘PM’ andReport Request = ‘Y’ then (PMP) Process PM<<Contributions/Distributions>> ELSIF Operand 2 = ‘CN’ and ReportRequest = ‘Y’ OR Operand 2 = ‘DN’ and Report Request = ‘Y’ then (CDC)Process PM <<Management Fees>> ELSIF Operand 2 = ‘MF’ and Report Request= ‘F’ then (PMM) Process PM <<Commissions>> ELSIF Operand 2 = ‘CM’ then(PCM) Process PM <<Federal Taxes>> ELSIF Operand 2 = ‘FT’ then (PMF)Process PM <<State Taxes>> ELSIF Operand 2 = ‘ST’ then (PMS) Process PMELSE Message “Invalid Operand 2” STOP ENDIF END

Process the Detail Records Maintenance Routine (AORS)

Note: Leave all switches=1 until the last routine is completed. Thisforces the processing to loop through each succeeding routine untilcompleted. Then turn set all swtiches=0 so that the Scheduler willrevert back to the Command Program to read another transaction.<<Originate ADD>> IF OORR = ‘O’ and    AORS = ‘A’ then IF Process 1Switch = 0 then  Set Process 1 Switch = 1  Initiate Process BS ELSIFProcess 2 Switch = 0 then  Set Process 2 Switch = 1  Initiate ProcessPI/PA ELSIF Process 3 Switch = 0 then  Set Process 3 Switch = 1 Initiate Process TS ELSIF Process 4 Switch = 0 then  Set Process 4Switch = 1  Initiate Process PM ELSE  Set Process 1 Switch = 0  SetProcess 2 Switch = 0  Set Process 3 Switch = 0  Set Process 4 Switch = 0ENDIF <<Reverse ADD>> ELSIF OORR = ‘R’ and    AORS = ‘A’ then IF Process5 Switch = 0 then Set Process 5 Switch = 1 Initiate Process BS ELSIFProcess 6 Switch = 0 then Set Process 6 Switch = 1 Initiate ProcessPI/PA ELSIF Process 7 Switch = 0 then Set Process 7 Switch = 1 InitiateProcess TS ELSIF  Process 8 Switch = 0 then Set Process 8 Switch = 1Initiate Process PM ELSE Set Process 5 Switch = 0 Set Process 6 Switch =0 Set Process 7 Switch = 0 Set Process 8 Switch = 0 ENDIF <<OriginateSUB>> ELSIF OORR = ‘O’ and    AORS = ‘S’ then IF Process 9 Switch = 0then Set Process 9 Switch = 1 Initiate Process BS ELSIF Process 10Switch = 0 then Set Process 10 Switch = 1 Initiate Process PI/PA ELSIFProcess 11 Switch = 0 then Set Process 11 Switch = 1 Initiate Process TSELSIF Process 12 Switch = 0 then Set Process 12 Switch = 1 InitiateProcess CG ELSIF Process 13 Switch = 0 then Set Process 13 Switch = 1Initiate Process PM ELSE Set Process 9 Switch = 0 Set Process 10 Switch= 0 Set Process 11 Switch = 0 Set Process 12 Switch = 0 Set Process 13Switch = 0 ENDIF <<Reverse SUB>> ELSIF OORR = ‘R’ and    AORS = ‘S’ thenIF Process 14 Switch = 0 then Set Process 14 Switch = 1 Initiate ProcessBS ELSIF Process 15 Switch = 0 then Set Process 15 Switch = 1 InitiateProcess PI/PA ELSIF Process 16 Switch = 0 then Set Process 16 Switch = 1Initiate Process TS ELSIF Process 17 Switch = 0 then Set Process 17Switch = 1 Initiate Process CG ELSIF Process 18 Switch = 0 then SetProcess 18 Switch = 1 Initiate Process PM ELSE Set Process 14 Switch = 0Set Process 15 Switch = 0 Set Process 16 Switch = 0 Set Process 17Switch = 0 Set Process 18 Switch = 0 ENDIF ENDIF

A first embodiment of the processing for the subtransaction processingmodule 64 is provided in the flowcharts of FIGS. 9-A through 9-B, FIGS.10, 11, 12, 13 and 14. Note that for simplicity, error handling andrelated validity checking steps have been omitted. However, theperformance of such steps is within the scope of the present invention,as one skilled in the art will appreciate.

A second pseudo-code embodiment of the transaction processing controller52 follows.

Pseudo-Code for Processing for the Subtransaction Processing Module 64

BEGIN  DO WHILE List of Subtransactions in the TT Table is Valid SelectNext Row of Operator. Operand 1, and Operand 2 from TT into WorkingStorage /* To choose the specific input field (or column) */ IF Operand1 = ‘N’ Set Value = Net Amount from Input String ELSIF Operand 1 = ‘I’SetValue = Interest from Input String ELSIF Operand 1 = ‘P’ Set Value =Principal from Input String ELSIF Operand 1 = ‘H’ Set Value = AmountUnits from Input String ELSIF Operand 1 = ‘U’ Set Value = Amount Unitsfrom Input String ELSIF Operand 1 = ‘C’ Set Value = Cost Basis fromInput String ELSIF Operand 1 = ‘V’ Set Value = Amount Units * Curr Pricefrom Input String ELSIF Operand 1 = ‘F’ Set Value = Federal Taxes fromInput String ELSIF Operand 1 = ‘S’ Set Value = State Taxes from InputString ELSIF Operand 1 = ‘L’ Set Value = Local Taxes from Input StringELSIF Operand 1 = ‘M’ Set Value = Management Fees from Input String ELSEMessage “Invalid Operand 1”, Details ENDIF /* To Adjust for Plus orMinus */ IF Operator = ‘P’ then Set Multiplier = +1 ELSIF Operator = ‘M’then Set Multiplier = −1 ENDIF /* To Adjust for Originate or Reversal */IF OORR = ‘O’ then Set Multiplier = Multiplier * +1 ELSIF OORR = ‘R’ SetMultiplier = Multiplier * −1 ENDIF /* Test for Total Unit Changes  */ IFOperand 2 = ‘TU’ then Add Value to AM - Total Units Add Value to EA -Total Units /* Test for Income Cash Changes  */ IF Operand 2 = ‘IC’ then/* Add to First Controls - Account Master  */ Add Value to AM - IncomeCash Add Value to AM - Units /* Add to Second Controls - EntityAttribute */ Add Value to EA - Invested Income Add Value to EA - Units/* Add to Third Controls - General Ledger  */ IF Number of Entries = 1then Add Value to GL - Income Cash ELSIF Number of Entries = 2 then IFValue > 0 then IF ICD >= 0 then  Add Value to GL - Income Cash DemandELSE ICD < 0  Add (Value - ICO) to GL - Income Cash Demand  Set Zero toGL - Income Cash Overdraft ENDIF ELSIF Value <= 0 then IF ICD < 0 then Add Value to GL - Income Cash Overdraft ELSE ICD >= 0 then  Add(Value - ICD) to GL - Income Cash Overdraft  Set Zero to GL - IncomeCash Demand ENDIF ELSE Message “Invalid Value”, Details ENDIF Add Valueto Uninvested Income ELSE Message “Invalid Number Entries”, DetailsENDIF /* Test for Principal Cash Changes  */ ELSIF Operand 2 = ‘PC’ then/* Add to First Controls - Account Master  */ Add Value to AM -Principal Cash Add Value to AM - Units /* Add to Second Controls -Entity Attribute */ Add Value to EA - Invested Principal Add Value toEA - Units /* Add to Third Controls - General Ledger  */ IF Number ofEntries = 1 then Add Value to GL - Principal Cash ELSIF Number ofEntries = 2 then IF Value > 0 then IF PCD >= 0 then  Add Value to GL -Principal Cash Demand ELSE PCD < 0  Add Value to GL - Principal CashDemand  Set Zero to GL - Principal Cash Overdraft ENDIF ELSIF Value <= 0then IF PCD < 0 then  Add Value to GL - Principal Cash Overdraft ELSEPCD >= 0 then  Add (Value - PCD) to GL - Principal Cash Overdraft  SetZero to GL - Principal Cash Demand ENDIF ELSE Message “Invalid Value”,Details ENDIF ELSE Message “Invalid Number Entries”, Details ENDIF AddValue to Uninvested Principal /* Test for Invested Income Changes  */ELSIF Operand 2 = ‘II’ then /* Add to First Controls - Account Master */ Add Value to AM - Invested Income /* Add to Second Controls - EntityAttribute */ Add Value to EA - Invested Income /* Add to ThirdControls - General Ledger  */ /* Update Assets */ Add Value to ACN-Assets /* Update Liabilities */ IF ACN-Liab = ‘ ‘ then Add Value toInvested Income ELSE Add Value to ACN_Liabilities ENDIF /* Test forInvested Principal Changes  */ ELSIF Operand 2 = ‘IP’ then /* Add toFirst Controls - Account Master  */ Add Value to AM - Principal Cash /*Add to Second Controls - Entity Attribute */ Add Value to EA - InvestedPrincipal /* Add to Third Controls - General Ledger  */ /* Update Assets */ Add Value to ACN - Assets /* Update Liabilities */ IF ACN_Liab = ‘ ‘then Add Value to Invested Principal ELSE Add Value to ACN_LiabilitiesENDIF /* Test for Other Customized Reporting Changes  */ ELSIF Operand 2= ‘I’ and Report Request = ‘Y’ OR Operand 2 = ‘E’ and Report Request =‘Y’ then (IEE) Process IE (PME) Process PM ELSIF Operand 2 = ‘R’ andReport Request = ‘Y’ OR Operand 2 = ‘D’ and Report Request = ‘Y’ then(IEC) Process RD (PMC) Process PM /* Test for other PerformanceMeasurement Data  */ ELSIF Operand 2 = ‘PM’ and Report Request = ‘Y’then (PMP) Process PM ELSIF Operand 2 = ‘CN’ OR Operand 2 = ‘DN’ then(CDC) Process PM ELSIF Operand 2 = ‘MF’ then (PMM) Process PM ELSIFOperand 2 = ‘CM’ then (PCM) Process PM ELSIF Operand 2 = ‘FT’ then (PMF)Process PM ELSIF Operand 2 = ‘ST’ then (PMS) Process PM ELSE Message“Invalid Operand 2”, Details ENDIF /* Test for Detail Record Maintenanceof Financial Instruments   */ IF AORS != ‘ ‘ then *********** CALLPORTFOLIO ADJUSTER 110 *********** ENDIF  ENDDO END

Pseudo-Code for Performance Measurement (PM) Processing related to theLicensee Performance Measurement Table 104

BEGIN IF  Trxn = ‘A’ and Type = ‘O’ OR Trxn = ‘S’ and Type = ‘R’ (whichmeans ADD) SELECT Data into Working Storage from PM Record IF Error thenINSERT INTO PM Record, Details IF Error then Message “INSERT PM Error”,Details Goto Write Reject Report ENDIF ELSE Increment Units by amount tobe increased UPDATE Data to Table / Row IF Error Message “UPDATE PMError 1”, Details Goto Write Report Error ENDIF ENDIF ELSIF Trxn = ‘A’and Type = ‘R’ OR Trxn = ‘S’ and Type = ‘O’ (which means SUBTRACT)SELECT Data into Working Storage from PM Record IF Error then Message “SELECT PM Error 2”, Details Goto Write Report Error ENDIF IF Units =‘ALL” and All Other Balances in the Row are Zero then DELETE from Table/ Row IF Error Message “DELETE PM Error”, Details Goto Write ReportError ENDIF ELSE Decrement Units by Amount to be reduced UPDATE PI SETDetails IF Error then Message “UPDATE PM Error 2”, Details Goto WriteReport Writer ENDIF ENDIF ELSE Null ENDIF Goto EOJ <<Write RejectReport>> INSERT into Reject Table, Details IF Error STOP ENDIF <<EOJ>>Null END

Pseudo-Code for Income/Expense Processing (IE) Processing Related to theCustomer Income Statement (Income/Expense) Table 96

BEGIN IF Trxn = ‘Debit’ and Type = ‘O’   (which means ADD) OR Trxn =‘Credit’ and Type = ‘O’ then SELECT Data into Working Storage from IERecord IF Error then INSERT INTO IE Table, Details IF Error then Message“INSERT IE Error 1”, Details Goto Write Report Error ENDIF ELSEIncrement Units by amount to be increased UPDATE Data to Table / Row IFError then Message “UPDATE IE Error 1”, Details Goto Write Report ErrorENDIF ENDIF ELSIF Trxn = ‘Debit’ and Type = ‘R’ (which means SUBTRACT)OR Trxn = ‘Credit’ and Type = ‘R’ then SELECT Data into Working Storagefrom IE Record IF Error then Message “SELECT IE Error 2”, Details GotoWrite Report Error ENDIF IF Units = ‘ALL” then DELETE from Table / RowIF Error then Message “DELETE IE Error”, Details Goto Write Report ErrorENDIF ELSE Decrement Units by Amount to be reduced UPDATE IE SET DetailsIF Error then Message “UPDATE IE Error 2”, Details Goto Write ReportWriter ENDIF ENDIF ELSE Null ENDIF Goto EOJ <<Write Reject Report>>INSERT into Reject Table, Details IF Error then STOP ENDIF <<EOJ>> NullEND

Pseudo-Code for AORS Processing (Portfolio Adjuster 110 Processing)

BEGIN /* The End AORS Switch is a global switch that signals the end ofall AORS processing */ /* otherwise known as the Detail Record (or Row)Maintenance Processing. */ /* The switch is originally set = 0. Eachcalled routine ends by setting the switch = 1. */ Set End AORL Switch =0 DO WHILE End AORS Switch = 0 IF Trxn = “ADD” then IF Type = ‘O’ then************ CALL Original Add Module 114 (Originate Add) ************IF Error Message “No OADD Routine” Goto Write Reject Report ENDIF ELSIFType = ‘R’ then ************ CALL Reverse Add Module 118 (Reverse Add)************ IF Error Message “NO RADD Routine” Goto Write RejectRoutine ENDIF ELSE Message “Invalid O OR R Code for ADD”, Details GotoWrite Reject Report ENDIF ELSIF Trxn = ‘SUBTRACT’ then IF Type = ‘O’then ************ CALL Original Sell Module 122 (Originate Subtract)************ IF Error then Message “No OSUB Routine”, Details Goto WriteReject Report ENDIF ELSIF Type = ‘R’ then ************ CALL Reverse SellModule 126 (Reverse Subtract) ************ IF Error then Message “NoRSUB Routine, Details Goto Write Reject Report ENDIF ELSE Message“Invalid O OR R for SUBTRACT”, Details Goto Write Reject Report ENDIFELSE Message “Invalid Transaction”, Details Goto Write Reject ReportENDIF Goto EOJ <<Write Reject Report>> INSERT into Reject Table IF Errorthen STOP ENDIF Set End AORL Switch =1 <<EOJ>> Null ENDDO END

A first embodiment of the processing for the balance sheet table 130 isprovided in the flowchart of Fig. BAL-SHT. Note that for simplicity,error handling and related validity checking steps have been omitted.However, the performance of such steps is within the scope of thepresent invention, as one skilled in the art will appreciate.

A second pseudo-code embodiment of the processing for the balance sheettable 130 follows.

Balance Sheet Processing (BS) BEGIN IF AORL = ‘A’ and OORR = ‘O’ (whichmeans ADD) AND AORL = ‘S’ and OORR = ‘R’ then SELECT Data into WorkingStorage from BS Record IF Error then INSERT INTO BS Table, Details IFError then Message “INSERT BS Error’, Details Goto Write Reject TableENDIF ELSE Increment Units by amount to be increased UPDATE Data toTable / Row IF Error Message “UPDATE BS Error 1”, Details Goto WriteReport Error ENDIF ENDIF ELSIF AORL = ‘A’ and OORR = ‘R’ (which meansSUBTRACT) OR AORL = ‘S’ and OORR = ‘O’ then SELECT Data into WorkingStorage from BS Record IF Error then Message “SELECT BS Error 2”,Details Goto Write Report Error ENDIF IF Units = ‘ALL” then DELETE fromTable / Row IF Error Message “DELETE BS Error”, Details Goto WriteReport Error ENDIF ELSE Decrement Units by Amount to be reduced UPDATEIE SET Details IF Error then Message “UPDATE BS Error 2”, Details GotoWrite Report Writer ENDIF ENDIF ELSE Null ENDIF Goto EOJ <<Write RejectReport>> INSERT into Reject Table, Details IF Error STOP ENDIF <<EOJ>>Null END

Pseudo-Code For Processing The Capital Gains Table 140

BEGIN IF AORL = ‘S’ and Type = ‘O’ (which means ADD) SELECT Data intoWorking Storage from CG Record IF Error then INSERT INTO CG Table,Details IF Error then Message “INSERT CG Table”, Details Goto WriteReport Error ENDIF ELSE Increment Units by amount to be increased UPDATEData to Table / Row IF Error Message “UPDATE CG Error 1”, Details GotoWrite Report Error ENDIF ENDIF ELSIF AORL = ‘S ’ and Type = ‘R’ (whichmeans SUBTRACT) SELECT Data into Working Storage from CG Record IF Errorthen Message “SELECT CG Error 2”, Details Goto Write Report Error ENDIFIF Units = ‘ALL” then DELETE from Table / Row IF Error Message “DELETECG Error”, Details Goto Write Report Error ENDIF ELSE Decrement Units byAmount to be reduced. UPDATE IE SET Details IF Error then Message“UPDATE CG Error 2”, Details Goto Write Report Writer ENDIF ENDIF ELSENull ENDIF Goto EOJ <<Write Reject Report>> INSERT into Reject Table,Details IF Error STOP ENDIF <<EOJ>> Null END

-   Note: do not turn switch OFF or back to 0 as these swithces indicate    which processes remain.

Pseudo-Code for Original Add Module 114 Processing

BEGIN IF Process 1 Switch = 0 then Set Process 1 Switch = 1 ********CALL BS ******** ELSIF Process 2 Switch = 0 then Set Process 2 Switch =1 ******** CALL PI ******** ELSIF Process 3 Switch = 0 then Set Process3 Switch = 1 ******** CALL PA ******** ELSIF Process 4 Switch = 0 thenSet Process 4 Switch = 1 ******** CALL TS ******** ELSIF Process 5Switch = 0 then Set Process 5 Switch = 1 ******** CALL PM ******** SetEnd AORS Switch = 1 Notes End of AORS Processing ELSE NULL ENDIF***************** CALL Subtransaction Scheduler 62 ***************** END

Pseudo-Code for Reverse of Add Module 118 Processing

Note: Do not turn switch OFF or back to 0 as these switches indicatewhich processes remain. BEGIN  IF Process 6 Switch = 0 then Set Process6 Switch = 1 ******** CALL BS ********  ELSIF Process 7 Switch = 0 thenSet Process 7 Switch = 1 ********** CALL PI **********  ELSIF Process 8Switch = 0 then Set Process 8 Switch = 1 ******** CALL PA ******** ELSIF Process 9 Switch = 0 then Set Process 9 Switch = 1 ******** CALLTS ********  ELSIF Process 10 Switch = 0 then Set Process 10 Switch = 1********* CALL PM ********* Set End AORS Switch = 1   Notes End of AORSProcessing  ELSE NULL  ENDIF  *****************  CALL SubtransactionScheduler 62  ***************** END

PSEUDO-CODE FOR ORIGINAL SELL MODULE 122 PROCESSING

BEGIN  IF Sell-Method = ‘LOT’ then   Select LOT Amount into WorkingStorage from BS record   IF Amount Sold > Lot Amount in Working Storagethen Message “Lot Amount > Amount Available” Goto Write Reject Report  ENDIF   IF Process 11 Switch = 0 then  Set Process 11 Switch = 0*************** CALL BS ***************   ELSIF Process 12 Switch = 0then  Set Process 12 Switch = 0 ********** CALL PI **********   ELSIFProcess 13 Switch = 0 then  Set Process 13 Switch = 0 ********** CALL PA**********   ELSIF Process 14 Switch = 0 then Set Process 14 Switch = 0********** CALL CG **********   ELSIF Process 15 Switch = 0 then  SetProcess 15 Switch = 1 ********** CALL TS **********   ELSIF Process 16Switch = 0 then  Set Process 16 Switch = 0 ********** CALL PM **********  ELSIF Process 17 Switch = 0 then  Set Process 17 Switch = 0 **********CALL TL ********** Set End AORS Switch = 1    Notes End of AORSProcessing   ELSE NULL   ENDIF   *****************   CALL SUBTRACTIONSCHEDULER 62   *****************  ELSE   Select all LOTS into TemporaryWorking Storage Table   Licn/Acct/Asset/Purch/Amt/Cost/Unit-Cost/ROWID)  Set Total Amount Sold = Data Entry Amount Sold   IF Total AmountSold > Total Amount Available then Message “Total Amount Sold > TotalAmount Available”, Details Goto Write Reject Report   ENDIF   Avg-Factor= 1   IF Sell-Method = “AVG” then Avg-Factor = (Total Amount Sold /Total Amount Available)   ENDIF  <<Sell Multiple Lot Routine>>  DO WhileTotal Amount Sold = 0 IF Total Amount Sold > 0 then  IF Sell-Method =‘FIF’ or ‘ ‘ then   Select LOT Amount Available into WS Lot Amount   Where Purch = MIN (Purch)  ENDIF ELSIF  IF Sell-Method = ‘LIF”  Select LOT Amount Available into WS Lot Amount    Where Purch =MAX(Purch)  ENDIF ELSIF  IF Sell-Method = ‘LCF’   Select LOT AmountAvailable into WS Lot Amount    Where Unit-Cost = MIN(Unit-Cost)  ENDIFELSIF  IF Sell-Method = ‘HCF”   Select LOT Amount Available into WS LotAmount    Where Unit-Cost = MAX(Unit-Cost)  ENDIF ELSE  <<forSell-Method = ‘AVG’ or ‘ALL’>>   IF Amount Sold * Avg Factor < WS LotAmount then    UPDATE Temporary Table Lot Amount    for Amount Sold ELSE  DELETE Total Row Temporary Table ENDIF **********   IF Process 11Switch = 0 then Set Process 11 Switch = 0 *************** CALL BS***************   ELSIF Process 12 Switch = 0 then Set Process 12 Switch= 0 ********** CALL PI **********   ELSIF Process 13 Switch = 0 then SetProcess 13 Switch = 0 ********** CALL PA **********   ELSIF Process 14Switch = 0 then Set Process 14 Switch = 0 ********** CALL CG **********  ELSIF Process 15 Switch = 0 then Set Process 15 Switch = 1 **********CALL TS **********   ELSIF Process 16 Switch = 0 then Set Process 16Switch = 0 ********** CALL PM **********   ELSIF Process 17 Switch = 0then Set Process 17 Switch = 0 ********** CALL TL ********** Set EndAORS Switch = 1   Notes End of AORS Processing   ELSE NULL   ENDIF  Decrement Total Amount Sold by Cap Gain Lot Amount   Increment the eLOT Number   *****************   CALL SUBTRANSACTION SCHEDULE 62  *****************  ENDIF ENDDO   ENDIF   <<EOJ>>   NULL  END

Originate Sell Routine

BEGIN IF Sell-Method = ‘LOT’ then Select LOT Amount into Working Storagefrom BS record. IF Amount Sold > Lot Amount in Working Storage thenMessage ″Lot Amount > Amount Available″ Goto Write Reject Report ELSE*************** CALL BS Routine *************** ENDIF ********** CALLPIPA ********** ********** CALL CG ********** ********** CALL TS********** ********** CALL PM ********** ********** CALL CG ******************** CALL TL ********** ELSE Select All LOTS into TemporaryWorking Storage Table Licn/Acct/Asset/Purch/Amt/Cost/Unit-Cost/ROWID)Set Total Amount Sold = Data Entry Amount Sold IF Total Amount Sold >Total Amount Available then Message “Total Amount Sold > Total AmountAvailable”, Details Goto Write Reject Report ENDIF Avg-Factor = 1 IFSell-Method = ‘AVG’ then Avg-Factor = (Total Amount Sold / Total AmountAvailable) ENDIF DO While Total Amount Sold = 0 IF Total Amount Sold > 0then IF Sell-Method = ‘FIF’ or ‘ ‘ then Select LOT Amount Available intoWS Lot Amount Where Purch = MIN (Purch) ENDIF ELSIF IF Sell-Method =‘LIF” Select LOT Amount Available into WS Lot Amount Where Purch = MAX(Purch) ENDIF ELSIF IF Sell-Method = ‘LCF’ Select LOT Amount Availableinto WS Lot Amount Where Unit-Cost = MIN(Unit-Cost) ENDIF ELSIF IFSell-Method = ‘HCF” Select LOT Amount Available into WS Lot Amount WhereUnit-Cost = MAX (Unit-Cost) ENDIF ELSE <<for Sell-Method = ‘AVG’ or‘ALL’>> IF Amount Sold * Avg Factor < WS Lot Amount then UPDATETemporary Table Lot Amount for Amount Sold ELSE DELETE Total RowTemporary Table ENDIF ********** CALL BS   with the amount of LOT sold********** ENDIF ********** CALL PIPA ********** ********** CALL TS********** ********** CALL PM ********** ********** CALL CG   with theamount of LOT sold ********** ********** CALL TL ********** DecrementTotal Amount Sold by Cap Gain Lot Amount Increment the LOT Number ENDIFENDDO ENDIF Goto EOJ <<Write Reject Report>> INSERT into Reject Table IFError then STOP ENDIF <<EOJ>> END

Pseudo-Code for Reverse of Original Sell Module 126 Processing

BEGIN  IF Process 18 Switch = 0 then Set Process 18 Switch = 1 ********CALL BS   with the amount of LOT sold ********  ELSIF Process 19 Switch= 0 then Set Processor 19 Switch = 1 ******** CALL PI ********  ELSIFProcess 20 Switch = 0 then Set Process 20 Switch = 1 ******** CALL PA********  ELSIF Process 21 Switch = 0 then Set Process 21 Switch = 1******** CALL TS ********  ELSIF Process 22 Switch = 0 then Set Process22 Switch = 1 ********* CALL PM *********  ELSIF Process 23 Switch = 0then Set Process 23 Switch = 1 ******** CALL CG   with the amount of LOTsold ********  ELSIF Process 24 Switch = 0 then Set Process 24 Switch =1 ******** CALL TL ******** Set End AORL Switch = 1     Notes End ofAORS Processing  ELSE NULL  ENDIF  *****************  CALLSubtransaction Scheduler 62  ***************** END

Pseudo-Code for Processing Model #4 For All INSERTS, UPDATES, andDELETES to all Tables

BEGIN  IF Trxn is ’ADD’ then   SELECT Data in Working Storage   IF Errorthen    INSERT INTO Table, Details    IF Error then     Message “INSERTError”, Details     Goto Write Reject Report    ENDIF   ELSE   Increment the Details    UPDATE Set Table, Details    IF Error then    Message “UPDATE Error ADD”, Details     Goto Write Reject Report   ENDIF   ENDIF  ELSIF Trxn is ‘SUBTRACT’ then   SELECT Data intoWorking Storage    IF Error then     Message “SELECT Error Subtract”,Details     Goto Write Reject Report    ENDIF   If One or More Amounts >One or More Values from   Existing Record then    ADD to Reject Report   IF Error then     Message “INSERT Reject SUBTRACT”, Details     GotoWrite Reject Report    ENDIF   IF Details = ‘ALL” then    DELETE FromTable, Details    IF Error then     Message “DELETE Error”, Details    Goto Write Reject Report    ENDIF   ELSE    Decrement the Details   UPDATE SET, Details    IF Error then     Message “UPDATE ErrorSUBTRACT”, Details     Goto Write Reject Report    ENDIF   ENDIF  ENDIF Goto EOJ  <<Write Reject Report>>  INSERT INTO Reject Table, Details IF Error then   Message “INSERT Reject Table Error”, Details   STOP ENDIF  <<EOJ>>  NULL END

Pseudo-Code for Processing the Trade Settlement Table 142

BEGIN  IF  Trxn = ‘A’ and Type = ‘O’ OR Trxn = ‘S’ and  Type = ‘O’ (which means ADD)   INSERT into TS table, Details   IF Error then   Message “INSERT TS Error 1”, Details    Goto Write Report Error   END ELSIF Trxn = ‘A’ and Type = ‘R’ OR Trxn = ‘S’ and Type = ‘R’  (whichmeans SUBTRACT)   SELECT Data into Working Storage from TS Record   IFError then    Message “SELECT TS Error 2”, Details    Goto Write ReportError   ENDIF   DELETE from Table/Row   IF Error    Message “DELETE TSError”, Details    Goto Write Report Error   ENDIF  ELSE   Null  ENDIF Goto EOJ  <<Write Reject Report>>  INSERT into Reject Table, Details  IF Error    STOP   ENDIF  <<EOJ>>  Null END

Pseudo-Code for Processing the Customer Cash Flow(Receipts/Disbursements) Table 100

BEGIN  IF  Trxn = ‘Receipt’ and Type = ‘O’ (which means ADD)  OR Trxn =‘Disbursement’ and Type = ‘O’ then   SELECT Data into Working Storagefrom RD Record   IF Error then    INSERT INTO RD Table, Details    IFError then     Message “INSERT RD Error”, Details     Goto Write ReportError    ENDIF   ELSE    Increment Units by amount to be increased   UPDATE Data to Table/Row    IF Error then     Message “UPDATE RDError 1”, Details     Goto Write Report Error    ENDIF   ENDIF  ELSIFTrxn = ‘Receipt’ and Type = ‘R’ (which means SUBTRACT)  OR   Trxn =‘Disbursement’ and Type = ‘R’   SELECT Data into Working Storage from RDRecord   IF Error then    Message “ SELECT RD Error 2”, Details    GotoWrite Report Error   ENDIF   IF Units = ‘ALL” then    DELETE fromTable/Row    IF Error     Message “DELETE RD Error”, Details     GotoWrite Report Error    ENDIF   ELSE    Decrement Units by Amount to bereduced    UPDATE IE SET Details    IF Error then     Message “UPDATE RDError 2”, Details     Goto Write Report Writer    ENDIF   ENDIF  ELSE  Null  ENDIF  Goto EOJ  <<Write Reject Report>>  INSERT into RejectTable, Details   IF Error then    STOP   ENDIF  <<EOJ>>  Null END

Pseudo-Code for Processing the Pending Adjustment Table 138

BEGIN  IF  Trxn = ‘A’ and Type = ‘O’ OR Trxn = ‘S’ and Type = ‘R’ (which means ADD)  AND Trade Date<Income Ex-Date then   SELECT Datainto Working Storage from PA Record   IF Error then    INSERT INTO PATable, Details    IF Error then     Message “INSERT PA Error”, Details    Goto Write Report Error    ENDIF   ELSE    Increment Units by amountto be increased    UPDATE Data to Table/Row    IF Error     Message“UPDATE PA Error 1”, Details     Goto Write Report Error    ENDIF  ENDIF  ELSIF Trxn = ‘A’ and Type = ‘R’ OR Trxn = ‘S’ and Type = ‘O’ (which means SUBTRACT)  AND  Trade Date > Income Ex-date + 1 then  SELECT Data into Working Storage from PA Record   IF Error then   Message “ SELECT PA Error 2”, Details    Goto Write Report Error  ENDIF   IF Units = ‘ALL” then    DELETE from Table/Row    IF Error    Message “DELETE PA Error”, Details     Goto Write Report Error   ENDIF   ELSE    Decrement Units by Amount to be reduced    UPDATE PASET Details    IF Error then     Message “UPDATE PA Error 2”, Details    Goto Write Report Writer    ENDIF   ENDIF  ELSE   Null  ENDIF  GotoPA-EOJ  <<Write Reject Report>>  INSERT into Reject Table, Details   IFError    STOP   ENDIF  <<PA-EOJ>>  Null END

Pseudo-Code for Processing the Pending Income Table 134

BEGIN  IF Trxn = ‘A’ and Type = ‘O’ OR Trxn = ‘S’ and Type = ‘R’  (whichmeans ADD)  AND Trade Date < Income Ex-Date then   SELECT Data intoWorking Storage from PI Record   IF Error then    INSERT INTO PI Table,Details    IF Error then     Message “INSERT PI Error”, Details     GotoWrite Reject Report    ENDIF   ELSE    Increment Units by amount to beincreased    UPDATE Data to Table/Row    IF Error     Message “UPDATE PIError 1”, Details     Goto Write Report Error    ENDIF   ENDIF  ELSIFTrxn = ‘A’ and Type = ‘R’ OR Trxn = ‘S’ and Type = ‘O’  (which meansSUBTRACT)  AND  Trade Date > Income Ex-date + 1 then   SELECT Data intoWorking Storage from PI Record   IF Error then    Message “ SELECT PIError 2”, Details    Goto Write Report Error   ENDIF   IF Units = ‘ALL”then    DELETE from Table/Row    IF Error     Message “DELETE PI Error”,Details     Goto Write Report Error    ENDIF   ELSE    Decrement Unitsby Amount to be reduced    UPDATE PI SET Details    IF Error then    Message “UPDATE PI Error 2”, Details     Goto Write Report Writer   ENDIF   ENDIF  ELSE   Null  ENDIF  Goto PI-EOJ  <<Write RejectReport>>  INSERT into Reject Table, Details   IF Error    STOP   ENDIF <<PI-EOJ>>  Null END

N_gine File (or Table) Structure and Likely Order of Creationcorresponding with FIGS. 4-A through 4-E

Data Source Institutional Profile LM Licensee Master User-Definable LULicensee Users User-Definable LT Licensee Account Type User-Definable LDLicensee Default Definitions User-Definable LL Licensee General LedgerDefinitions User-Definable LS Licensee Diversification SchemeUser-Definable LP Licensee Performance Group User-Definable LN LicenseeSummary Names User-Definable LW Licensee Service WholesalersUser-Definable LR Licensee Service Resellers User-Definable CustomerProfile AO Account Objective User-Definable AL Account Legal CapacityUser-Definable AJ Account Jurisdiction User-Definable AR AccountRepresentatives User-Definable AN Account Registration NamesUser-Definable AM* Account Master User-Definable AC AccountCommunication Links User-Definable Transaction Profile TM** TransactionMaster User-Definable “Driving” File TP** Transaction ProcessorUser-Definable “Driving” File TR Transactions - Recurring User-Definable“Driving” File Entity Profile EM Entity Master Public Market Data EA*Entity Attribute User-Definable ET Entity Transaction User-DefinableLicensee Status SG* System General Ledger User-Definable SJ* SystemTransaction Journal Sytem Defined “Driven” File ST System TradeSettlement System Defined “Driven” File SS System Summary Table SystemDefined SR System Reject Table System Defined SC System TransactionCount System Defined Customer Status CS Customer Income Statement(Income/Expense) System Defined “Driven” File CF Customer Cash Flow(Receipts/Disbursements) System Defined “Driven” File CB* CustomerBalance Sheet System Defined “Driven” File CG Customer Capital GainSystem Defined “Driven” File CI Customer Pending Income System Defined“Driven” File CA Customer Pending Capital Adjustments System Defined“Driven” File CP* Customer Performance Measurement System Defined“Driven” FileNotes:*denotes Primary Control Tables**denotes “Driving Tables”

SAMPLE DATA FOR LICENSE GENERAL LEDGER DEFINITION TABLE (LL)

Licensee Asset Accounting Accounting Identifier or Liab Control NumberName LICN1 A A05 Municipal Bonds LICN1 A A07 Corporate Bonds LICN1 A A10Common Stocks LICN1 A A12 Mutual Funds LICN1 A A13 InternationalCurrencies LICN1 A A15 Oil Partnerships LICN1 A A20 Real EstatePartnerships LICN1 A A30 Foreign Equities LICN1 A A35 Objects of ArtLICN1 A A40 Jewelry LICN1 A A45 Homes LICN A A50 Automobiles LICN A A90Derivatives LICN2 A W10 MSA/RSA - North LICN2 A W20 MSA/RSA - East LICN2A W30 MSA/RSA - South LICN2 A W40 MSA/RSA - West LICN2 A L10 AlabamaLICN2 A L20 Alaska . . . . . . . . . LICN2 A L500 Wyoming LICN2 A S10Major Market 1 LICN2 A S20 Major Market 2 LICN2 A S30 Major Market 3 . .. . . . . . . LICN2 A S1000 Major Market N LICN3 A C10 Cash LICN3 A C20Other Current Assets LICN3 A C30 Fixed Assets LICN3 A C40 DepreciationLICN3 A C50 Intangible Assets LICN1 L L05 Uninvested Income LICN1 L L10Invested Income LICN1 L L15 Uninvested Principal LICN1 L L20 InvestedPrincipal LICN1 L L30 Personal Notes LICN1 L L40 Mortgages LICN1 L L90Income LICN1 L L60 Short-Term Liabilities LICN1 L L65 Deferred TaxesLICN1 L L70 Long-Term Liabilities LICN1 L L75 Net Worth

SAMPLE DATA FOR SYSTEM GENERAL LEDGER TABLE

Asset Accounting Licensee or Account Control Accounting Master Liab TypeNumber Name LICN1 A 000 000 Financial Services Assets LICN1 A 100 000Pension Trust LICN1 A 100 A01 Income Cash Demand LICN1 A 100 A02 IncomeCash Overdraft LICN1 A 100 A03 Principal Cash Demand LICN1 A 100 A04Principal Cash Overdraft LICN1 A 100 A07 Corporate Bonds LICN1 A 100 A10Common Stocks LICN1 A 100 A15 Oil Partnerships LICN1 A 100 A20 RealEstate Partnerships LICN1 A 100 A30 Foreign Equities LICN1 A 200 000Investment Advisory LICN1 A 200 A01 Income Cash Demand LICN1 A 200 A02Income Cash Overdraft LICN1 A 200 A03 Principal Cash Demand LICN1 A 200A04 Principal Cash Overdraft LICN1 A 200 A05 Municipal Bonds LICN1 A 200A07 Municipal Bonds LICN1 A 200 A10 Common Stocks LICN1 A 200 A12 MutualFunds LICN1 A 200 A13 International Currencies LICN1 A 200 A15 OilPartnerships LICN1 A 200 A20 Real Estate Partnerships LICN1 A 100 A30Foreign Equities LICN1 A 100 A90 Financial Derivatives LICN1 A 300 000Estates LICN1 A 300 A01 Income Cash Demand LICN1 A 300 A02 Income CashOverdraft LICN1 A 300 A03 Principal Cash Demand LICN1 A 300 A04Principal Cash Overdraft LICN1 A 300 A05 Municipal Bonds LICN1 A 300 A07Corporate Bonds LICN1 A 300 A10 Common Stocks LICN1 A 300 A12 MutualFunds LICN1 A 300 A15 Oil Partnerships LICN1 A 300 A20 Real EstatePartnerships LICN1 A 300 A30 Foreign Equities LICN1 A 300 A35 Objects ofArt LICN1 A 300 A40 Jewelry LICN1 A 300 A40 Homes LICN1 A 300 A50Automobiles LICN1 A 400 000 Settlement Accounts - Buy LICN1 A 400 A01Income Cash Demand LICN1 A 400 A02 Income Cash Overdraft LICN1 A 400 A03Principal Cash Demand LICN1 A 400 A04 Principal Cash Overdraft LICN1 A400 A05 Corporate Bonds LICN1 A 400 A07 Municipal Bonds LICN1 A 400 A10Common Stocks LICN1 A 400 A15 Oil Partnerships LICN1 A 400 A20 RealEstate Partnerships LICN1 A 400 A30 Foreign Equities LICN1 A 500 000Settlement Accounts - Sell LICN1 A 500 A01 Income Cash Demand LICN1 A500 A02 Income Cash Overdraft LICN1 A 500 A03 Principal Cash DemandLICN1 A 500 A04 Principal Cash Overdraft LICN1 A 500 A05 Corporate BondsLICN1 A 500 A07 Municipal Bonds LICN1 A 500 A10 Common Stocks LICN1 A500 A15 Oil Partnerships LICN1 A 500 A20 Real Estate Partnerships LICN1A 500 A30 Foreign Equities (AND/OR) LICN2 A 1000 000 CommunicationAssets LICN2 A 1000 W00 Wireless Communications LICN2 A 1000 W10MSA/RSA - North LICN2 A 1000 W20 MSA/RSA - East LICN2 A 1000 W30MSA/RSA - South LICN2 A 1000 W40 MSA/RSA - West LICN2 A 2000 L00Landline Communications LICN2 A 2000 L10 Alabama LICN2 A 2000 L20 Alaska. . . . . . LICN2 A 2000 L500 Wyoming LICN2 A 3000 S00 SatelliteBroadcast LICN2 A 3000 S10 Major Market 1 LICN2 A 3000 S20 Major Market2 LICN2 A 3000 S30 Major Market 3 . . . . . . LICN2 A 3000 S1000 MajorMarket 4 (AND/OR) LICN3 A 0000 000 Corporate Assets LICN3 A 9000 000Domestic Subsidiary LICN3 A 9000 C10 Cash LICN3 A 9000 C20 Other CurrentAssets LICN3 A 9000 C30 Fixed Assets LICN3 A 9000 C40 Depreciation LICN3A 9000 C50 Intangible Assets LICN3 A 9000 000 Foreign Subsidiary LICN3 A9000 C10 Cash LICN3 A 9000 C20 Other Current Assets LICN3 A 9000 C30Fixed Assets LICN3 A 9000 C40 Depreciation LICN3 A 9000 C50 IntangibleAssets LICN3 L 000 000 Financial Services Liabilities LICN1 L 100 000Pension Trust LICN1 L 100 L15 Uninvested Principal LICN1 L 100 L20Invested Principal LICN1 L 200 000 Investment Advisory LICN1 L 200 L05Uninvested Income LICN1 L 200 L10 Invested Income LICN1 L 200 L15Uninvested Principal LICN1 L 200 L20 Invested Principal LICN1 L 300 000Estates LICN1 L 300 L05 Uninvested Income LICN1 L 300 L10 InvestedIncome LICN1 L 300 L15 Uninvested Principal LICN1 L 300 L20 InvestedPrincipal LICN1 L 300 L30 Personal Notes LICN1 L 300 L40 Mortgages LICN1L 400 000 Settlement - Buy LICN1 L 400 L15 Uninvested Principal LICN1 L400 L20 Invested Principal LICN1 L 500 000 Settlement - Buy LICN1 L 500L15 Uninvested Principal LICN1 L 500 L20 Invested Principal (AND/OR)LICN2 L 1000 000 Communications LICN2 L 1000 000 Wireless LICN2 L 1000L90 Income LICN2 L 2000 000 Landline LICN2 L 2000 L90 Income LICN2 L3000 000 Satellite Broadcast LICN2 L 3000 L90 Income (AND/OR) LICN3 L9000 000 Domestic Subsidiary LICN3 L 9000 L60 Short-Term LiabilitiesLICN3 L 9000 L65 Deferred Taxes LICN3 L 9000 L70 Long-Term LiabilitiesLICN3 L 9000 L75 Net Worth LICN3 L 9000 000 Foreign Subsidiary LICN3 L9000 L60 Short-Term Liabilities LICN3 L 9000 L65 Deferred Taxes LICN3 L9000 L70 Long-Term Liabilities LICN3 L 9000 L75 Net Worth

A Standardized Method for Naming the Programs (or SQL Scripts) and DataElements of Real-time Multiprocessed Automated Applications

The specific invention is a standardized file naming convention to beused in the automatic generation of program code for multiplelarge-scale transaction processing applications (such as securitiestrading, telecommunications billing, and work management) onmulti-processing computers (using 4, 8, 16, 32 processors) with 100%auditability of user-defined controls. The standardized file namingconvention is totally independent of any specific

a.) application such as accounts receivable, customer billing, etc.,

b.) industry such as financial services, telecommunications, or workmanagement,

c.) hardware manufacturer such as Compaq, Digital, HP, IBM, NCR, Unisys,

d.) operating system such as MS-DOS, UNIX, OpenVMS, MVS, etc.,

e.) relational database management system such as Oracle, Sybase, MS-SQLServer,

f.) computer language such as SQL, COBOL, Fortran, PL/1, etc.

The standard naming convention contains the fewest number of charactersin any naming conventions; namely, eleven characters used by MS-DOS. Thenaming convention of MS-DOS uses eight characters as a file name andthree characters as a file extension wherein the user may define a filename using the alphabet and selected other characters. While thisflexibility is suitable for home use are a small number of files andusers, it is not acceptable for large-scale enterprise-wide applicationswith large number of files and large number of supporting technicians.Hence, the need for enterprise-wide standards.

The standard file naming convent n contains six elements that permit thetechnician to readily identify the functionality of the specific script(or program) without looking at its contents. Using ANSI Standardstructured Query Language as an example language, the six elements are:

a.) a 2-character mnemonic for the SQL commands such as: Mnemonic ANSIStandard SQL Commands CT Create Table SF Select From Table DF DeleteFrom DT Drop Table II Insert Into SI Select Into CS Create Sequence DSDrop Sequence CI Create Index DI Drop Index RV Review RT Retest RSReset, etc.

b.) a 2-character mnemonic for the application name such as MnemonicUser Defined Application Name Examples ST Securities Trading TCTelecommunications Billing WM Work Management, etc.

c.) a 2-character mnemonic for the table (or file name) such as MnemonicUser-Defined Table Name Examples AM Account Master Name/Address/Etc. SMSecurities Master DC Detail Calls XB External Billing, etc.

d.) a 1-character mnemonic for the table cluster role such as MnemonicStandard Table Roles M Master I Input A Accepts R Rejects H History SSummary 1 Master History 2 Accepts History O Output

e.) a 1-character mnemonic for the table cluster type such as MnemonicStandard Table Types M Master J Journal T Temporary 1-9 Index Numbers

-   f.) a 3-character extension is then added to the file name depending    upon

the type of operating system being used such as MS-DOS, UNIX, OpenVMS,etc. and

whether or not the file is a source file for programmer use or acompiled file (or stored procedure) for machine use.

Hence, script name examples are:

CTXBMDMM.SQL—Create Table for the External Billing System, MasterDefinition Table Cluster, Master Table, and Master Role for SQL use.

DTXBDCOJ.SQL—Drop Table for the External Billing System, Detail CallCluster, Output Table, and Journal Role for SQL use.

Circumstances Leading to the Invention

The circumstances leading to the invention of a standard SQL scriptnaming convention are:

a.) one programmer will rarely adhere to the same naming conventionsover time and unless an acceptable standard is defined each succeedingprogrammer added to the job will only complicate the issue by bringingtheir own standards. Hence, software maintenance becomes a matter ofknowing which programmer wrote which program at what time.

b.) without a naming standard any programmer has no idea of whatfunctions the programming is performing without opening the program andexamining the program code. This process produces create inefficientmaintenance by existing programmers and inefficient training for newprogrammers.

c.) Competitive pressures are mounting for the efficient of softwaremaintenance.

Advantage of the Invention

Because no duplicate script names are permitted the name of each SQLScript should

a.) convey to the user the precise use of each SQL Script and

b.) permit the storage of all SQL scripts in a one SQL Script Library,or directory.

A standard naming convention also permits the user to determine whatscripts may be automatically executed in sequence by use of a SQLcommand script, which is a single SQL script containing a list of SQLscripts to be executed in sequence. Hence, any single SQL scriptscontained in the SQL Library can be reused in many different SQL commandscripts.

Although any standard naming convention represents a unique entityseparate and apart from the other technologies described immediatelyabove, this particular naming convention is unique in that it embracesall of the logical information necessary to readily identify the role ofthe script in the total system.

Detailed Description of Invention:

std_name is a standard naming convention that constructs names forprograms (or SQL Scripts), system tables, table clusters, and dataelements. The seven basic elements are: 1.) org_name Organization 2 2.)com_name SQL Command 2 3.) app_name Application 2 4.) tab_name Table 25.) rol_name Table Role 1 6.) typ_name Table Type 1 7.) col_name Column(or Field) 4

std_name defines both “external” names used by the operating system and“internal” names used by the specific program. 1.) clu_name Cluster Name4 2.) sys_name System Table Name 6 3.) ext_name Extension Name 3 4.)sql_name SQL Script Name 11 (8 name plus 3 extension)

where the SQL Script Names are used by the operating systems.

The “internal” resulting names are: 1.) tab_iden Table Iden Name 4 2.)col_name Column (or Field) Name 4 3.) dat_name Data Element Name 8 ormore, in increments of 4

where the Data Element Names are used by the programs (or SQL Scripts).

External Names used by the operating system in identifying programs (orSQL Scripts) are created by employing the following naming components:com_name  SQL Command Mnemonic  app_name Application Name Mnemonic  tab_name Table Name Mnemonic    rol_name Table Role Name Mnemonic    tab_name Table Type Name Mnemonic      ext_name Extension MnemonicExamples: 1 2 3 4 5 6 7 8 . 9 10 11 C T X B M D M M . S Q L S F X B M DM M . S Q L   clu_name  tab_iden sys_name ext_name   sql_name

Internal Names used by the program (or SQL Script) in processing thedata elements are created by employing the following naming components:5 6 7 8 tab_name    Table Name Mnemonic   rol_name   Role Name Mnemonic    typ_name  Type Name Mnemonic       col_name  Column name Examples: MD M M LNAM ... for last name M D M M FNAM ... for first name M D M MMNAM ... for middle name M D M M ADR1 ... address - 1st line M D M MADR2 ... address - 2cd line M D M M CITY ... city M D M M STAT ... stateM D M M ZIPC ... zip code dat_nameData Tracing

By addressing both the external names for the operating system and theinternal names for a specific program, the naming convention is globalin nature. In the event that one data element derives its source ofinput from another table rather than its own specific input screen, thenthe data name is extended by placing the table identifier of the tablesupplying the data between the first four and second four characters ofthe intended data name. Should the data be derived from another tablethat also derived its data from another table, then eight characters areplaced between the first four characters and the last four characters ofthe intended data name. In the fashion, the data name points backwardsthrough all of the preceding tables to the original source of data andits input form. This process is called “data tracing”, and it providesbenefits to programmers in the testing and debugging stages of softwaredevelopment by identifying the original source of data. Thus, “datatracing” provides the programmer with thorough documentation of the dataflow throughout an entire system.

Standard naming conventions do not apply to certain language extensionssuch as the script footings that, for example, specify the size of thetable to be created in a “Create Table” script.

The foregoing discussion of the invention has been presented forpurposes of illustration and description. Further, comments anddescription is not intended to limit the invention to the form disclosedherein. Consequently, variation and modification commensurate with theabove teachings, and within the skill and knowledge of the relevant art,are within the scope of the present invention. The embodiment describedherein above is further intended to explain the best mode presentlyknown of practicing the invention and to enable others skilled in theart to utilize the invention as such, or in other embodiments, and withthe various modifications required by their particular application oruses of the invention. It is intended that the appended claims beconstrued to include alternative embodiments to the extent permitted bythe prior art.

1-26. (canceled)
 27. A method for processing a financial transaction ona computing system using a plurality of processors comprising:retrieving, in response to a request to perform a financial transactionhaving a transaction identifier and input values, a unique subset ofuser-defined algorithms from a set of user-defined algorithms, whereinthe unique subset is associated with the transaction identifier via auser-defined transaction processing table, each user-defined algorithm,when executed by a processor on the input values, creates or changes adata record such that the unique subset of user-defined algorithmsassociated with the transaction identifier, when executed using theinput values, creates or changes data records stored in a database asnecessary to process the financial transaction; executing each of theuser-defined algorithms of the unique subset on the input values;wherein the unique subset of algorithms are executed concurrently ondifferent processors and the financial transaction is consideredprocessed when all algorithms in the unique subset of user-definedalgorithms have been executed on the input values.
 28. The method ofclaim 27, wherein each request further includes a licensee identifierand the set of user-defined algorithms is further associated with thelicensee identifier.
 29. The method of claim 27, wherein executing eachof the user-defined algorithms of the unique subset on the input valuescomprises: executing a user-defined algorithm that creates a data recordin a transaction journal file; executing a user-defined algorithm thatchanges a data record in a general ledger master table; executing auser-defined algorithm that changes a data record in an account mastertable; and executing a user-defined algorithm that changes a data recordin an entity attribute master table.
 30. The method of claim 27 furthercomprising: generating a transaction sequence number for the retrievedrequest to perform a financial transaction.
 31. The method of claim 29,wherein executing each of the user-defined algorithms of the uniquesubset on the input values comprises: executing a user-defined algorithmthat creates, changes or deletes a data record in a cash flow table;executing a user-defined algorithm creates, changes or deletes a datarecord in an income statement table; executing a user-defined algorithmthat creates, changes or deletes a data record in a capital gains table;executing a user-defined algorithm that creates, changes or deletes adata record in a balance sheet table; and executing a user-definedalgorithm that creates, changes or deletes a data record in aperformance measurement table.
 32. The method of claim 27, furthercomprising: if the transaction identify is not associated with a uniquesubset of user-defined algorithms from the set of user-definedalgorithms, writing the request to perform the financial transaction toa system reject table.
 33. The method of claim 27 further comprising: ifone of the algorithms fails to execute, reversing all algorithms of theunique subset that did execute; and writing the request to perform thefinancial transaction to a system reject table.
 34. The method of claim27 wherein each of the unique subset of algorithms is executedconcurrently on a different one of the plurality of processors.
 35. Themethod of claim 27 wherein at least one of the unique subset ofalgorithms is executed on a first processor concurrently with theexecution of at least one algorithm of a different unique subset ofalgorithms on a different processor.
 36. The method of claim 27 whereinat least one of the unique subset of algorithms is executed on a firstprocessor concurrently with the execution of at least two algorithms ofdifferent unique subsets of algorithms on different processors.
 37. Amethod for processing financial transactions on a multiprocessingmachine having a plurality of processors, each financial transactionhaving financial transaction data, the method comprising: maintaining aset of user-defined algorithms, each user-defined algorithm beingindependently and simultaneously processable by any one of the pluralityof processors in the multiprocessing machine and each user-definedalgorithm when processed on financial data adds, changes or deletes onlyone financial data record based on the financial data; receiving a firstfinancial transaction having a first user-defined financial transactiontype and first financial data; identifying, for the first financialtransaction, a first unique subset of user-defined algorithms from a setof user-defined algorithms based on the first user-defined financialtransaction type; processing each user-defined algorithm in the firstunique subset of user-defined algorithms on the first financial data;receiving a second financial transaction having a second user-definedfinancial transaction type and second financial data; identifying, forthe second financial transaction, a second unique subset of user-definedalgorithms from the set of user-defined algorithms based on the seconduser-defined financial transaction type; processing each user-definedalgorithm in the second unique subset of user-defined algorithms on thesecond financial data; and wherein all the user-defined algorithms inthe first unique subset of user-defined algorithms on the firstfinancial data and at least one of the second unique subset ofuser-defined algorithms are concurrently processed.
 38. The method ofclaim 37, wherein each user-defined algorithm changes only one financialdata record in only one user-defined financial report and includes anoperator, a first operand that identifies input data from the financialtransaction data, and a second operand that identifies the only one datarecord.
 39. The method of claim 37 further comprising: maintaining auser-defined transaction processing table that associates eachuser-defined transaction type with a unique subset of the set ofuser-defined algorithms including associating the first unique subset ofuser-defined algorithms with the first user-defined financialtransaction type and the second unique subset of user-defined algorithmswith the second user-defined financial transaction type.
 40. The methodof claim 37, wherein processing each unique subset of the set ofuser-defined algorithms associated with a user-defined transaction typecomprises: executing a user-defined algorithm on a first processor thatcreates a data record in a transaction journal file; concurrentlyexecuting a user-defined algorithm on a second processor that changes adata record in a general ledger master table; concurrently executing auser-defined algorithm on a third processor that changes a data recordin an account master table; and concurrently executing a user-definedalgorithm on a fourth processor that changes a data record in an entityattribute master table.
 41. The method of claim 37 further comprising:wherein the at least one of the second unique subset of user-definedalgorithms is completed prior to completion of processing all theuser-defined algorithms in the first unique subset of user-definedalgorithms.
 42. The method of claim 37 further comprising: receiving thesecond financial transaction after receiving the first financialtransaction; and completing processing of all of the user-definedalgorithms in the second unique subset of user-defined algorithms priorto completing the processing of all of the user-defined algorithms inthe first unique subset of user-defined algorithms.
 43. A financialtransaction multiprocessing system for an enterprise, each financialtransaction having a financial transaction type and financialtransaction data, comprising: a multiprocessing computer having aplurality of processors; a financial record database storing financialdata records; a database manager for creating, changing and deletingfinancial data records; a queue for receiving financial transactions forprocessing, wherein each financial transaction when processed results inadding, changing or deleting to at least one financial data record andwherein each financial transaction is associated with one of a pluralityof user-defined financial transaction types and includes financialtransaction data; an algorithm database storing a set of user-definedalgorithms, each user-defined algorithm capable of being processedconcurrently and independently with any other user-defined algorithm andeach user-defined algorithm when processed by any one of the pluralityof processors causing the database manager to add, change or delete afinancial data record; and a transaction processing table thatassociates each user-defined transaction type with a unique subset ofthe set of user-defined algorithms such that processing a firstfinancial transaction having a first financial transaction type andfirst financial transaction data is achieved by processing a firstunique subset of user-defined algorithms associated with the firstfinancial transaction type on the first financial transaction data. 44.The financial transaction multiprocessing system of claim 43 furthercomprising: a set of control tables; a set of user-defined controlalgorithms, each user-defined control algorithm when processed causingthe database manager to add, change or delete one or more data recordsin one or more control tables; and wherein the transaction processingtable further associates one or more user-defined control algorithmswith each user-defined financial transaction type.
 45. The system ofclaim 43 further comprising: a processor queue for user-definedalgorithms, the processor queue distributing queued user-definedalgorithms to processors as the processors become available.
 46. Thesystem of claim 43, wherein each user-defined algorithm includes onlyone operator and only a first operand and a second operand, the firstoperand identifying input data from the financial transaction data ofthe financial transaction to be processed, and the second operandidentifying the only one data record.